## Brian Fitzgerald · Klaas-Jan Stol · Sten Minör Henrik Cosmo

## The Digitalization Journey

Scaling a Software Business

## Scaling a Software Business

The Digitalization Journey

Brian Fitzgerald Lero - Irish Software Research Centre University of Limerick Limerick, Ireland

Sten Minör Mobile and Pervasive Comuting Institute (MAPCI) Lund University Lund, Sweden

Klaas-Jan Stol University of Limerick Limerick, Ireland

Henrik Cosmo Mobile and Pervasive Comuting Institute (MAPCI) Lund University Lund, Sweden

ISBN 978-3-319-53115-1 ISBN 978-3-319-53116-8 (eBook) DOI 10.1007/978-3-319-53116-8

Library of Congress Control Number: 2017941052

© The Editor(s) (if applicable) and The Author(s) 2017. This book is an open access publication

**Open Access** This book is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons. org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made. The images or other third party material in this book are included in the book's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the book's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use.

The publisher, the authors and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, express or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Printed on acid-free paper

This Springer imprint is published by Springer Nature The registered company is Springer International Publishing AG The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland Illustrations and design: Ove Jansson, www.monpetitstudio.fr

This work was supported, in part, by the Swedish Innovation Agency VINNOVA and Enterprise Ireland grant IR/2013/0021 and Science Foundation Ireland grant 13/RC/2094 and co-funded under the European Regional Development Fund through the Southern & Eastern Regional Operational Programme to Lero—the Irish Software Research Centre (www.lero.ie).

 This book is a product of a research project that tackled one of the key challenges currently facing the software industry in Europe, and indeed worldwide, namely, how do we transform our organization as software increasingly becomes a critical part of our business? How can we support the digitalization of assets and offerings?

This book presents the Scaling Management Framework (SMF), which is unique in the sense that it supports the above transformation in three domains: 1) products systems & services, 2) organization & business, and 3) methods & processes. These domains are interdependent and are integrated into a single model in the SMF.

The framework was developed in the SCALARE ("SCAling softwARE") project which was a pan-European project funded under the auspices of the ITEA (Information Technology for European Advancement), a program in the EU-REKA Cluster program that supports industry-driven research in the area of software-intensive systems & services.

The intensive case-study approach adopted throughout the project makes the framework highly relevant for today's businesses. The project members have drawn on over 300 years of software engineering and senior management experience conducting more than 30 company case studies companies in Germany, Ireland, Spain and Sweden.

The project was supported by Enterprise Ireland, Science Foundation Ireland, and the Swedish innovation agency, Vinnova.

The digitalization transformation in both industry and society has been ongoing for several decades. Companies in the telecom industry were early movers, whereas the automotive industry is currently in the midst of their digitalization journey. Digitalization implies a shift in focus from hardware and products towards software and services and possibly disruptive business models. This is a game-changer for most companies and the race is on right now.

You may be in a situation where you want to take the next step to increase your usage of software and services in your offerings. You need to do something, but you don't know what options you have, nor what actions you need to take.

**The SCALARE project\* draws on the Scaling Management Framework (SMF) to provide guidance on creating a roadmap for different scaling approaches such as Open Source, Lean & Agile and global software development.**

http://www.scalare.org \*

The answer to the question of "how to make a roadmap of our transformation?" can be found in NQRZOHGJHJOHDQHGIURPSUHYLRXVH[SHULHQFHVDQGWKH60)SURYLGHVDQHDV\ZD\WRÀQGLQIRUPDWLRQ that is relevant to you. The framework helps you to understand your own situation. It will help pin down what you want to achieve and how to use this knowledge to search for valid solutions. It also provides guidance to help include all personnel in the process, to use their knowledge about the company.

## The SCALARE team's objectives

There are many models that can be used to analyze and assess companies and their products. Often they have a grading system to evaluate whether they are good or bad. +RZHYHUWKH\DUHRIWHQDOVRTXLWHVSHFLDOL]HGIRUVSHFLÀFEXVLQHVVGRPDLQV

Considering the increasing importance of software throughout the entire company, the model must cover all perspectives of a software business, not just the technical aspects.

#### **This resulted in the integration of the three domains, product, process, and organization into a single model.**

 The6&\$/\$5(WHDPIRXQGLWYHU\GLIÀFXOWDQGLQGHHGPLVJXLGHGWRDUJXHWKHUHZDV only one way to accomplish the transformation. Presenting a smorgasbord of possible ways to improve, there would inevitably be arguments for different and additional practices. Instead, the SMF became a mechanism to design a structure where relevant real experiences could be added.

The model does not produce an evaluation grade for activities, but can be used to capture and describe many different situations.

Even though this reduced the model itself and made it simpler, it was still what we desired and needed.

### Co-created by industry and academia professionals

Brian Fitzgerald Lero/University of Limerick

Chief Scientist with Lero, the Irish Software Research Centre. He holds the Frederick Krehbiel II Professorship in Innovation in Business and Technology at the University of Limerick. His research focuses on innovative software development approaches.

Sten Minör MAPCI/Lund University PhD in Computer Science. Industrial experience from Ericsson and Sony Ericsson where he has held several senior positions within software development and strategy. He is innovation director at MAPCI - Mobile and Pervasive Computing Institute at Lund University and CEO of Sigrun Software Institute.

#### Ove Jansson Mon Petit Studio

Visual communicator since 2007. Prior to this, MSc in Computer Science and 12 years in software development and management. He visualizes time machines and other good ideas, such as the SMF.

This book has been written by the team that created the SMF. We have reduced the SMF to its essence, a format that's easier to comprehend. But it's not a handbook. It's for senior executives who need a proven guide to approach a transformation project. The book also facilitates communication, by establishing a common terminology.

Klaas-Jan Stol Lero/University of Limerick Research Fellow with Lero, the Irish Software Research Centre. He holds a PhD in Software Engineering from the University of Limerick. His research focuses contemporary software development approaches, in particular innersourcing, opensourcing, and crowdsourcing

.

Henrik Cosmo MAPCI/Lund University

MSc and Tech. Lic. in Software Engineering. 25 years of experience from the global wireless industry. Has held senior positions in large multinational companies as well as in small Silicon Valley startups, in organizations developing and operating software.

Lund University Professor in Software Engineering at Lund University, Sweden. His main research interests include software quality and em-

pirical software engineer-

**Martin Höst**

**Miguel Oltra Rodríguez** Schneider Electric

MSc in Telecommunication Engineering. 15 years of experience in research projects on topics such as software product lines, OSS practices & SOA.

**Anders Sixtensson** Softhouse

MSc and Tech. lic. in Electrical and SW Engineering. 30 years as consultant, manager and business developer in the field of business improvement in SW intensive products and organizations.

**Ulf Asklund** Lund University

PhD in Computer Science. Experience both from industry and research projects, with focus on how to improve product lifecycle management, configuration management, and product architecture.

ing.

**Max Sunemark** Addalot

MSc in Electrical Engineering. Over 20 years of experience as SW developer, project and line manager. Has held several senior manager positions at large international companies.

**Carl-Eric Mols** Sony Mobile Communications

Has close to 30 years of experience on telecommunication and mobile industry software, the last 8 years holding the position as Head of Open Source.

**Ulrika Bergman** Tieto

Customer Executive, Tieto. Holds a MSc in Electrical Engineering. More than 20 years of experience in large IT projects in telecom and the public sector.

**Anders Mattsson** Husqvarna

PhD in Software Engineering. He has 27 years of experience in industrial software development and research with focus on SW architecture and model driven development.

In addition to those on the previous page, others have been instrumental in the creation of this book. 7KRVHQDPHGDERYHKHOSHGWRIRUPXODWHWKHHVVHQFHRI 60),QWXUQWKH\ZHUHKHOSHGVLJQLÀFDQWO\E\ many individuals across the project who conducted the industry research, all the case studies that SMF builds on. They are named below:

**Jonas Ahnlund**, Lund University **Nicolas Martin-Vivaldi**, Addalot **Even Andre Karlsson**, Addalot **Horst Hientz**, Kugler Maag **Hans-Jürgen Kugler**, Kugler Maag

**Krzysztof Wnuk**, Lund University **Ola Morin**, Softhouse **Johan Kardell**, Softhouse **Marcus Degerman**, Softhouse **Donal O'Brien**, QUMAS

**Joanne O'Driscoll**, QUMAS **Ryan O'Sullivan**, QUMAS **John Burton**, Vitalograph **Ger Hartnett**, Goshido

We're in a business where most of our product features have to be realized with software. Adding software to a business is a complex enterprise, whether we start from scratch or take our products to the next level. There are as many ways to organize such product evolutions as there are people involved. However, reality leaves us no choice: we have to take the plunge in order to sustain our business. Fortunately, many companies have already embarked on such journeys. Based on numerous case studies with a variety of companies in different domains, we developed the Scaling Man-DJHPHQW)UDPHZRUN60)7KH60)FRGLÀHVSDVWH[SHULHQFHVDQGRIIHUVV\VWHPDWLFJXLGDQFHWR assess our starting point as well as our destination. This book is full of stories of companies, and we describe their journeys using the SMF. Ericsson is one such company, and we start telling their story next.

#### How a dozen software developers became several thousands in a few years – the story of a technical and an organizational boom

## Hello world

The big breakthrough for mobile telephony during the nineties is a part of technological history characterized by intense competition between innovative companies. For Ericsson Mobile Communications, it meant a period of explosive expansion of the mobile phone software development department in Lund, Sweden: growing from a handful of developers, to an army of thousands within a few years. While this story is from the days when mobile telephony was made into an everyday tool for billions of people, it's still highly relevant for all of us interested in scaling a business.

The software organization in Ericsson's mobile phones is a great example of an organization that just keeps growing and growing. It started in 1992 when Erics-VRQLQWURGXFHGWKHLUÀUVW\*60SKRQH\$WWKDWWLPHRQO\DGR]HQSHRSOHZRUNHG on the software for mobile phones. Eleven of them were working with the

technical and telecoms-related platform software. Only one of the developers was responsible for the phones' user interface. You could use the phone to make calls – but that's about all you could do.


Programmers were thrown into the project, only to drown in the complexity of maintaining existing functionality while developing new features

tations to have advanced features on all their devices.

As customers were demanding an increasing level of "mobility" and the ability to access a fast growing number of network services, Ericsson Mobile Communication's R&D department faced major challenges. The number of different phone models. The amount of software in phones grew exponentially and doubled

every 18 months – closely aligned with Moore's Law. Programmers were thrown into the project, only to drown in the complexity of maintaining existing functionality while developing new features. Teams were no longer co-located but were distributed over different sites. Every month, the technical complexity increased: more different phone models, more network services, more feature requests from customers, and more innovations from competitors. Mobile phone operators demanded a continuous stream of software updates to the phones they were selling and had no intention of waiting. In (ULFVVRQODXQFKHGWKH5WKHÀUVW´VPDUWSKRQHµ\$WWKLVWLPH(ULFVson had some 40 different phone models, and countless combinations of hardware, software, and infrastructure services.

14

It was time to take the plunge. As the software grew exponentially, the change process had to embrace the entire organization. Product and system architecture, organizational changes, business and development processes – all had to adapt in a coordinated manner towards a common goal. Rules for what can and cannot be done with the software had to be established. The organization needed to think in new ways, to invest in a software architecture that ZDVGHVLJQHGWRVFDOH,WEHFDPHFUXFLDOWRLQWURGXFHVWULQJHQWFRQÀJXUDWLRQPDQDJHPHQWWR control the wide variety of different software versions.

## **Common challenges with software**

"Our organization has become a software company. The problem is that we haven't realized that yet!" This is how the VP of a major semiconductor manufacturing company, traditionally seen as a classic hardware company, characterized the context in which software solutions were replacing hardware in their products. This organization knew precisely the threshold of reuse level for their hardware components before "designing for reuse" became cost-effective. However, no such sophistication was present in their software processes.

The digitalization of society is changing businesses more rapidly than ever seen before, there are FRXQWOHVVRWKHUVFHQDULRVHPHUJLQJ,WLVGLIÀFXOWWRÀQGDPDUNHWGRPDLQLQZKLFKWKHLQQRYDWLRQ does not depend on software.

**Our organization has become a software company. The problem is that we haven't realized that yet!**

For several years now, we have seen how traditional companies adopt novel and clever business concepts using digital technologies that integrate into our everyday life. Everything that can be digitalized is digitalized, and any data that can be collected is collected.

Technological advances, such as the emergence of cloud-based solutions, mobile devices and social media have paved the

way for this evolution. Take smart watches, for example, which are becoming very popular. By adding software to an ordinary watch, it can now access internet services which opens up a wide range of new possibilities and opportunities. The Smart watch is an excellent example of products that have emerged from digitalization.

What motivates these companies to transform their businesses, what are their goals, or to put it differently, what are the business drivers? The primary answer is that software affords development

of new business opportunities. Some companies see radical cost savings from digitalization, where others see revenue growth by creating innovative products and services. So, it's not surprising that traditional industries such as manufacturing are now in the midst of developing their digital strategies. Software has become a critical part of their product offerings, but they need to scale the business systematically in order to not lose momentum, or worse, to lose business altogether.

How do they do it? Needless to say, transforming software requires rethinking existing processes as well as incorporating new practices and tools. Studying other companies to see how they approached the transformation is a very useful exercise as it teaches us so many things. All of them have more or less created a new sort of IT organization. In the digitalized company, IT is not only about internal network services and technology, but also deals with business models and the digital platform for customer facing services and products. It's not unlikely that the traditional IT organizations dissolve and merge with development organizations as a consequence.

Obviously, IT is just one of the cogwheels in the digitalized business that need to spin in new ways. The entire organization will need a lift. As this chapter proceeds, it will become clear that it all boils down to a company's motivations to transform: the business drivers.

This is the point of departure for this book. The transformation journey can be done in a variety of ways, but ultimately we can categorize any software transforming activity to one of three domains product, process, or organization.

Knowing what needs to be done is quintessential when approaching the digital transformation. This book offers a method that will help your organization in three ways:

the map of the digital transformation. It helps you in creating a digitalization strategy.

of common drivers that will help you to find your digital transformation journey.

database with best practices and lessons learned from past digitalization transformations.

This book embodies three years of research that was conducted in a European project called "SCAling softwARE" – SCALARE for short – which was established by a consortium of partners in Germany, Ireland, Spain, and Sweden.

Over 30 case studies were conducted, involving companies in a variety of domains, ranging from pharma to automotive as well as emerging industries that aim to deliver IoT (Internet of Things) products and services.. Each case study is based on in-depth interviews with vice presidents, directors, managers, supervisors and front-line service employees.

Let's get back to the starting point of this book: why do companies need to transform? Answering this question will help later in this book, when we're pinpointing what journey a company needs to PDNH7RJXLGH\RXWKURXJKWKLVERRNZHKDYHGLVWLOOHGÀYHPDLQUHDVRQVWRHPEDUNRQDVFDOLQJ journey.

Drive revenue growth and outperform competitors with new business models

Increase quality, make operational expenditure savings and shorten time-to-market

Deal with organizational challenges (access to qual-LÀHGSHUVRQQHODELOLW\WR ramp resources, round the clock development, divide the work between different departments, and so on.)

Expand into new markets and geographies

Develop innovative new products and services, innovate in current products and services

7KHUHDUHRI FRXUVHPDQ\ZD\VWRGHÀQHDQGJURXSGLIIHUHQWEXVLQHVVGULYHUV:HKDYHFKRVHQWR XVHWKHÀQGLQJVIURPD+DUYH\1DVK&,26XUYH\FRQGXFWHGLQHQWLWOHG´.H\SULRULWLHVWKH board is looking for an IT department to address".

Where does your organization need to scale? Which of the business drivers are key to your organization? You may identify several drivers to match your business plan and digital strategy. You have to bear in mind that this has to be a cross-organizational effort, where the current IT department QHHGVWRVWHSXSDQGEHSDUWRIRUHYHQWDNHWKHOHDG7RGHÀQHWKHUROHRI WKH,7GHSDUWPHQWLV an essential part of the digital strategy.

Let's get back to the SCALARE project room. The eight standard scenarios, the map and the compass on your scaling journeys, are compilations of the most common repeated patterns that the SCALARE team observed during the various case

studies. In other words, a scenario based on real life scaling experiences in companies that all shared similar drivers.

This is how we should approach the scenarios. Which scenarios have similar drivers to ours? Since we may have several drivers to consider, our transformation journey could very well match several scenarios.

#### **Bottom-line:**

We have to get a clear picture of what drivers we have.

## Not to waste time

Page

Get an overview by reading the map. Find out how the framework fits into your picture by reading the compass. Then read what solutions there are by reading relevant journeys.

22

The Scaling Management Framework

**24**

Ways to find journeys relevant to you

Travel Brochures and Travel Stories

How you get there

B. Fitzgerald et al., *Scaling a Software Business*, DOI 10.1007/978-3-319-53116-8\_1 © The Author(s) 2017

Scaling software development is a complex enterprise that can be organized in a number of ways. Since the early days of computing, hundreds, if not thousands of software development methods have been proposed. What is becoming increasingly clear, however, is that the software development function affects the whole organization, not only its software developers. For example, as the software development workforce is expanding, the processes that are used may have to be adjusted to facilitate large-scale collaborations. Developing more and larger software-based products

requires consideration of architectural strategies such as the adoption of a software product line approach. The SMF covers three scaling domains to capture this complexity: product, organization, and process. It also captures the relationships between these domains.

To exemplify the scope of the SMF, let's consider the ÀFWLYH WHVW WRRO FRPSDQ\ \$XWR7HVW 7KH\ KDYH EHHQ very successful in their local market, but now have the opportunity to expand to Asia. The SMF may help them in the analysis of their software development and sup-

The Scaling Management Framework covers transformations in three domains

port organization. The SMF is not a tool for analyzing business models, but instead it can be used WRDQDO\]HVFDOLQJFKDQJHVWULJJHUHGE\IRULQVWDQFHWKHLQWURGXFWLRQRI QHZSURGXFWVDVSHFLÀF customer requirement or a new support organization.

The SMF can be used in several different ways to support the digital transformation journey. It offers systematic guidance for decision makers to identify scaling needs, to analyze scaling options DQGLPSOHPHQWWUDQVIRUPDWLRQVLQWKHWKUHHVFDOLQJGRPDLQV6LQFHWKH60)FOHDUO\GHÀQHVEHJLQ and end states of the transformations, management can easily measure the success of the transformation journey.

The framework is simple yet complete enough to suit all sorts of companies: small as large, local as global. It works equally well for companies that mainly deal with hardware but need to introduce software, as for companies that develop proprietary software and want to engage with Open Source communities.

The SMF offers a multi-dimensional view on the software-scaling phenomenon. The SMF canvas, an integral part of the SMF, is a tool for understanding and describing the scaling of software development. It's designed to be visualized on a whiteboard, along with post-it notes. To the left, we have the present, and to the right we have the desired future. The transformation happens in between the two.

It starts with top management to identify the drivers, the reasons to scale. These are typically the outcome of a digitalization strategy.

Next we observe the software development as a black box, focusing on performance, quality and other aspects that can be measured without knowing how they work. We know what we spend and how much we generate from the their work. These are basically the complaints and wishes of our top management, matters we also could use to measure the success of the transformation.

Having all this, we're ready to dive into the black box, the software model. Inside we have as well a present to

the left and a future to the right. But foremost, it's parted in the three scaling domains organization, SURFHVVDQGSURGXFW2XUZRUNLVWRÀQGWKHURRWFDXVHVWRWKHFXUUHQWLQDELOLWLHVDQGIRUHYHU\ cause come up with an idea of how we want it to be, ideally. This is done within all three domains and it is important that all inabilities are explained by at least one root cause.

7KHJDSEHWZHHQWKHSUHVHQWDQGWKHIXWXUHGHÀQHVWKHWUDQVIRUPDWLRQZKHUHWKHUHDOZRUNLV FDUULHGRXW,W·VDOVRZKHUHZHDGGWKHUHDOYDOXHRI 60)ZLWKVFHQDULRVWKDWLQFOXGHSUHGHÀQHG transitions. In fact, the lot of this book is about scenarios; they are that important. If we know that part of our digitalization for instance includes one of the Open Source transitions, then we'll just DGGDQRWHDERXWLWWKHUHLQWKHNH\WUDQVLWLRQVÀHOG

The drivers of the need to change.

The inabilities that make the transformation challenging.

Drivers Inabilities Desired abilities

The measurable GHšQLWLRQRIGRQH

Current set-up Desired set-up

Organization domain

Process domain

Product domain

The key activities that are needed to make the transformation possible.

## Drivers

'ULYHUVDUHWKHH[WHUQDOIDFWRUVWKDWLQÁXHQFHWKHVRIWZDUHGHYHORSPHQW3UHYLRXVGULYHUVPDGH you build your current product, ways of working and organization. But now, new drivers force you to create new solutions – to transform your software.

We need to clearly formulate why we want to make a change and scale our software development. If these drivers get too vague, also the solutions and eventually the implementation will be un-IRFXVHGDQGVRPHWLPHVQHYHUÀQLVKHG2SWLPDOO\WKHGULYHUVVKRXOGEHEDVHGRQWKHFRPSDQ\ strategy.

It seems simple to create the drivers, but it often turns out to be quite hard to decide on what OHYHOWKHGULYHUVVKRXOGEHGHÀQHG)RUH[DPSOHLVDGHPDQGRQ´DPRUHPRGXODUL]HGSURGXFWµ DGULYHU²RULQVWHDGDSRVVLEOHVROXWLRQWRWKHGULYHUWR´JHWDPRUHFRQÀJXUDEOHSURGXFWµ",V DFWXDOO\´DPRUHFRQÀJXUDEOHSURGXFWµUHDOO\DGULYHURULVDOVRWKLVDSRVVLEOHVROXWLRQWRFRSH with the requirement "to faster reach different markets"? We argue it is the latter and that the SUHYLRXVDUHVROXWLRQVWREHGHÀQHGLQWKHGRPDLQVRI WKHVRIWZDUHPRGHO

We might for instance need to pursuit new market opportunities through expansion or a com-

We provide a short-list of five high-level drivers, and how they can be translated into SMF transitions.

pany takeover. Or why not do as Amazon and start selling your internal development platform as a service? Do we need to extend the functionality in our current offering? The mobile phone industry has made that, seeing the mobile phone developed from being a communication device to also be our primary entertainment device. In regulatory requirements we need to comply with safety standards such as ISO 26262 (Road vehicles), or with software maturity

standards such as CMMI (Capability Maturity Model Integration). Such requirements will inevitable turn into drivers, since these are tickets to trade.

In addition to external drivers, it is also possible to have internal drivers. An internal driver is something you want to achieve, as you believe it will help you move in the right direction even though no external customer or market is requesting it right now. One such example is the company culture. It might not directly affect the close-term business, but will most likely affect the long-term results.

Since drivers are quite diverse and particular to every company, the SMF do not provide any model for analyzing and understanding drivers. Yet they need to be listed and understood before XVLQJWKHUHVWRI WKHPRGHO,QWKLVERRNKRZHYHUZHSURYLGHDVKRUWOLVWRI ÀYHKLJKOHYHOGULYers, and how they can be translated into SMF transitions.

## Software abilities

Drivers represent the trigger for the transformation of a business; they are the reasons to drive a transformation in one of the SMF domains. They are the fuel that starts a journey to get from current software abilities to desired software abilities.

Inabilities or growing pains are what currently stop us from achieving the desired drivers. The inabilities are mostly visible outside of the organization, for instance by other organizations within the company or outside the company by customers. Abilities have to be measurable, in order for us to know if we're getting any better. When we measure the abilities, the organization is considered being a black box.

Most abilities can be put into one of the following categories:


,WLVVRPHWLPHVGLIÀFXOWWRGLVWLQJXLVKEHWZHHQDGULYHUDQGDVRIWZDUHDELOLW\

Let's use the taxi car as an analogy. The drivers are the type of customers and their requirements, including school children, business people, disabled people, party crowd in need to make short

as well as long drives. The abilities include for instance cost, speed and capacity of the car to meet the business needs. The driver's ability to avoid traf-ÀFMDPDQGÀQGWKHVKRUWHVWZD\WRWKHULJKWDGGUHVV is probably the most important competition factor.

Software abilities usually end up as Key Performance Indicators or Balanced Scorecards in the organization.

Some abilities are not really sprung out of drivers,

but can still be a reason for the company to make improvements. The SMF refer to these inabilities and drivers as growing pains. Examples of growing pains are when a company has trouble UHFUXLWLQJFRPSHWHQWSHUVRQQHORUVXIIHUIURPLQVXIÀFLHQWFRQÀJXUDWLRQPDQDJHPHQWDQGYHUVLRQ handling systems to manage parallel feature development.

## Software model set-up

When we work with the drivers and abilities, we treat software development as a black box. The black box is called the software model.

The purpose of the software model domain is to:


Opening up the box, we see domains as the software organization, how they work, how they are organized and how the product looks. We cannot only focus on one of these domains, but need to look at the entire complex situation. The dependencies to organizations outside the box are usually many and intertwined. And it's not just the present, the future might as well require new relations to be established between the software organization and the rest of the company. For instance, if the company wants to start using Open Source software, the legal organization will be needed.

The canvas is for this reason divided into the three domains: organization, process, and product. \$GRPDLQFRYHUVDOODVSHFWVWKDWDUHLPSRUWDQWWRDQDO\]HLQRUGHUWRGHÀQHRXULPSRUWDQWFKDU-DFWHULVWLFVZLWKLQWKHGRPDLQV7KH\DOVRGHÀQHZKDWFKDQJHVZHQHHGWRGRZLWKLQWKHGRPDLQV WRWUDQVIRUPDQGIXOÀOO\RXUGULYHUV

Our work is to make an inventory of the current ways we're working, and we should use post-its DQGGRFXPHQWRXUÀQGLQJVRQWKHFDQYDV:LWKRXUGULYHUVDVDFRPSDVVLW·VWLPHWRVWDUWQHVWing. It is natural to begin with our inabilities. Are there any existing assets we can exploit and are there any roadblocks in the way we're working? It's time to ask all these questions we have on our mind.

Why? Why? Why?

In the following sections we describe the individual domains and their building blocks.

## Product domain

The product domain covers the software architecture of your product or service. This is more complex than just describing a software application as a monolith. The offering might be based RQVHUYLFHVUDWKHUWKDQDVLQJOHSURGXFW,WPLJKWHYHQLQFOXGHDFRPSOHWHHFRV\VWHPWKDWGHÀQHV KRZSURGXFWVDQGVHUYLFHVFDQLQWHUDFWDQGKRZWRFRQÀJXUHWKHVH

The SMF divides this domain into three building blocks:


7KHSURGXFWRUVHUYLFHLVWKHÀQDOUHVXOWRI WKHZKROHVRIWZDUHGHYHORSPHQWOLIHF\FOHHIIRUW

### Process domain

The process domain covers all aspects about how the product or service is developed and tested. This domain is divided in two building blocks:


### Organization domain

The organization domain covers aspects such as how a company is structured, how the company's culture is and how are each individual employee treated. The organization domain is divided in four building blocks:


## Transitions

The key transitions are the most important activities in order to get where we aim; altogether they constitute the very transformation journey, the fun part where all the magic happens.

The transition area of the canvas consists of a set of actions, each one representing a transformation of the software model from a current state to a desired state. Transitions can be so general their descriptions turn into patterns.

Examples of transitions are:


6HYHUDOFURVVGRPDLQWUDQVLWLRQVDUHXVXDOO\QHHGHGWRDGGUHVVDOOGHVLUHGDELOLWLHVWKDWLVWRIXOÀOO the drivers). In the example above, to meet the requirement and lower the development cost, many changes are likely needed. No business situation is the other alike. We have to pay good attention to this phase.

## It all fits together

7RVXPPDUL]HWKH60)IXOÀOOPRVWFRPSDQLHV·QHHGWRVFDOHLQWHUPVRI WKHLUH[LVWLQJRUQRQH[ isting software.

Drivers and abilities gives the structure to describe the reason for scale and the main metrics needed to measure the improvements. Look into case studies with similar drivers and abilities as the business we want to change. Working with drivers and abilities is very important to understand the reason, why you want to scale.

The software model with its three domains and their building blocks gives a structure to describe the actual implementation of the product or service. Each domain studies the building blocks and also the dependencies between implementations in different blocks.

The SMF defines several standard change scenarios, but still most companies have to customize their unique set of changes in order to implement their particular drivers.

The connection between the domains, how things works in each one of them, and the current inabilities encourage

us to think through all domains and their building blocks in order to understand why we have the inabilities. This is part of the self-assessment to understand what needs to be improved.

The transitions – capturing the needed change from current situation to desired situation is the most important part of the SMF. Experts within each domain will have to discuss possible chang-HVDQGWKHLULPSDFW<HVWKH60)GHÀQHVVHYHUDOVWDQGDUGFKDQJHVFHQDULRVEXWVWLOOPRVWFRPSDnies have to customize their unique set of changes in order to implement their particular drivers. Exactly as the SMF was intended to be used.

Tran Driver Inability Current organization process Current product Why do we do what we do, as we do? Why? Why? Why? Why? Why? Why? Why?

Why do we want to scale the business? What abilities would we need to be able to scale successfully?

> Can we measure the abilities as KPIs?

## How the canvas can be used

For this example, we will have a look at Spotify. Its service allows us to search for artists, albums, titles, labels and genres, and access music tracks from major as well as independent labels. Streaming of music has in many regions become the predominant way we listen to music.

How did Spotify achieve to make the software service so successful? According to the vast amount of articles that have been written on the topic, they simply seem to have decided to "create the best streaming music service". We can assume this was their driver. What they intended to measure was the number of Spotify streams. This was their desired ability. The higher the number of steams (listeners), the more successful they became. Let's try to express their journey with a few SMF post-it notes.

Create the best

To accomplish what their driver boldly stated, their software engineering department made this transformation.

Most importantly, to stimulate motivation and innovation, they introduced an Agile Engineering Culture. They also organized themselves in loosely coupled but aligned Autonomous Squads (small, self-organized teams). A Squad has end-to-end responsibility of what they build (design, commit, deploy, maintain and operate). They did try the software development methodology SCRUM for a while, but decided quite early to skip this way of working. A more generic agile methodology was simply more relevant for them.

They introduced continuous delivery with small and frequent releases to their customers. The software architecture was changed to enable decoupled releases (synchronized releases were too time-consuming). Their product development approach was based on Lean Start-up**\*** principles.

The Lean Startup. Crown Publishing Group. Eric Ries \*

 **Ways to find** 

:HGLGQ·WLQWHQGWKLVERRNWREHUHDGIURPVWDUWWRÀQLVK²EXW\RXDUHPRUHWKDQZHOFRPHWRGR so. Instead, we've written this book with busy managers in mind – people, like you, who don't have the time to read the whole book carefully but only the sections that are relevant to your particular business. We've therefore organized this book along a set of journeys.

**The easiest way to read the book is to turn page and read through the brief scenario descriptions. So if you are interested in Open Source you can just read the two Open Source chapters.**

**A second way to read the book is to have a look at the five categories of drivers, presented to the right on this page spread. If you for instance want increased revenues, then there are two journeys that can help, Servitization and Open Source (business driven).**

**Drive revenue growth and outperform competitors with new business models**

**Develop innovative new products and services or improve current products and services**

**Journey 1 Journey 3 Journey 7**

#### **Expand into new markets and geographies**

**Increase quality, make OPEX savings and improve time to market** 

#### **Deal with leadership challenges**

5351

#### Journey 1 – Co-operate in a community

4UJdz8ȢǼȦHJ It is admittedly an irresistible temptation to us, getting free software. The cost to maintain a particular part of our system is sometimes far too high. It is possible to develop common components in cooperation with others and gain from proven, de-facto standard software. Entering this path would encourage us to further advance how we do business.

#### Journey 2 – Building ecosystems

4UJdz8ȢǼȦHJ By now we've been into Open Source development for quite a while. Even the management has acknowledged the contra productivity in just using free software without giving back, that sharing is caring. We imagine the ultimate Open Source strategy, to go beyond the communities and orchestrate our own ecosystem, to divide and conquer.

#### Journey 3 – Add supplementary services

8JWǽǮǺǯ\_FǹǮȣȡ Customers are getting more and more demanding: they want it all and they want it QRZQRWWRPHQWLRQWKHÀHUFHFRPSHWLWLRQ7KHLURIIHULQJVDUHEDVLFDOO\WKHVDPHDV ours, equally or even better priced. Our product-oriented business slows us down. We need to move towards a service-driven business model.

&LNǰǪ

#### Journey 4 – Deliver 24/7

2XUFXVWRPHUVDUHGLVVDWLVÀHGZLWKRXUDELOLW\WRGHOLYHUZKDWWKH\ZDQWDQGZKHQ they want it. The time we need to test and deliver makes it hard to meet deadlines and steals time from development. As if it weren't bad enough, serious bugs have VWDUWHGWRSDVVWKHORXSH,I ZHFDQGHOLYHUFRQWLQXRXVO\ZHFDQUHÀQHRXUVHUYLFHV by running more experiments and do-learn-adapt cycles with our market.

#### Journey 5 – Pump up the volume

We have the greatest product; every batch we produce literally sells out as soon as it leaves the production line. We need to throw in more people, to build the products faster and increase the volumes. Innovation is not a matter at this point, neither is the cost. What matters is how to get around the many dependencies between products, services and departments.

#### Journey 6 – Agile and disciplined

As manufacturer in the automotive industry, everything we do need to adhere to industry standards. The Niagara-like waterfall processes makes even small things WDNHDJHV:HZRXOGVXUHO\EHQHÀWIURPDPRUHÁH[LEOHZRUNÁRZEXWWKH2(0V kill every discussion by saying "Agile software development lack discipline." We need to break this barrier.

#### Journey 7 – Outside the box

How about moving parts of our software development to India? Learnings suggest WKDWLWPLJKWEHGLIÀFXOWWKDWDFRVWUHGXFWLRQLVQ·WPDGHWKDWHDV\<HWKLJKO\VNLOOHG and talented engineers can still be recruited at a relatively low cost. Incorporated VHQVLEO\ZHZRXOGJDLQEDFNWKHÁH[LELOLW\ZHODFN:HQHHGWRJRRIIVKRUH

'FXǮț XTȭǿǧȦȥ JSǫǮȡȥJWǮdzȪ

#### Journey 8 – First things first

It didn't happen overnight, but still, if we had staid calm when the business took off, we wouldn't have been in this situation. 15 additional programmers have joined the two of us, and our development process is getting a bit shaky. We need to adopt essential engineering principles and possibly re-factor the software architecture.

&LNǰǪ

&LNǰǪ

4ǢXǬTȦǮSǫ

4ZYǷȢǼȦHNdzȪ

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

B. Fitzgerald et al., *Scaling a Software Business*, DOI 10.1007/978-3-319-53116-8\_2 © The Author(s) 2017

## **Co-develop in a community Building ecosystems Add supplementary services Deliver 24/7 Pump up the volume Agile and disciplined Outside the box First things first** Scaling with Open Source Scaling with Servitization Scaling with Agile Scaling with Outsourcing or Offshoring Basic Software Engineering Scaling with Open Source Scaling with Agile Scaling with Agile

<Think big. How to transform a software business in a good way> Copyright (C) <2016> <S.W. Scalare>

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as

published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

Open Source refers to software that has been made available to the public and is free to use in any application.

63

The source code is tied with a copyright license, giving any receiver of the source code the rights to use, modify and redistribute the code for free. Think of free as in free speech, not free beer**\***.

You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>.

"Free software is a matter of liberty, not price. To understand the concept, you should think of free as in free speech, not as in free beer."

—Richard Stallman

The Open Source movement is several decades old, but it wasn't until the turn of the millennium that major companies entered the game. Traditional business wisdom had suggested that source code, which was seen as a "crown jewel" of a software company represented valuable LQWHOOHFWXDOSURSHUW\WKDWVKRXOGUHPDLQFORVHGWRPD[LPL]HSURÀW:LWK2SHQ6RXUFH6RIWZDUH

There is always someone who knows the solution to a given software problem

(OSS) development the effectiveness of this tactic is reduced since the source code is made publicly available.

The original intention with Open Source is that software is collectively developed, typically in an Open Source community characterized by collaboration, transparency and self-organization. This development model is an interesting value proposi-

tion to companies, as development is potentially done quickly, involving hundreds of developers, ZKRZRUNIRUIUHH,QYROYLQJPDQ\SHRSOHWRÀ[GHIHFWVJDYHULVHWR/LQXV·V/DZ**\***: given enough eyeballs, all bugs are shallow. In other words, there is always someone who knows the solution to a given software problem. This may also lead to new and better ideas from someone who has stood on the sideline thus far—these "lurkers" may decide to contribute after using the software for a while.

In recent years, this image of OSS developers has become outdated, and many companies are now actively participating in OSS communities for a variety of reasons.

However, no matter the business incentives, the initiative to start working with OSS communities is almost always taken within the development organization. As any development organization, they simply need to:

A claim formulated by Eric S. Raymond, named in honor of Linus Torvalds \*


Even if the work with Open Source preferably ought to be sanctioned by management it often starts as skunkwork**\***.

Those Open Source drivers are particularly appealing for the development organization whose software is characterized by a large heap of legacy and proprietary code that haven't been maintained and modernized for a long time.

When the cost to maintain the code supersedes what is invested in new features development, Open Source offers an irresistible temptation for engineering. Business as usual – to constantly postpone innovation and delay novelties in the offering to the future – simply isn't a viable option.

A skunkwork project is a small and loosely structured group of people who research and develop a project primarily for the sake of radical innovation. \*

So the engineers decides to "accidentally" use Open Source as a novel way to cut corners when solving development challenges they have at hand. This is very common, but of course not the preferred way forward. Quite likely, they don't have formal approval from the management.

The reason they don't include management and keep doing skunkwork may vary. The not-invented-here argument is often heard. Management may not trust third-party code. Until only a few years ago, Open Source was considered by most as a hacker's phenomenon and a headache for the Legal department. The threshold to explain what Open Source is really about and why VRIWZDUHGHYHORSPHQWZRXOGEHQHÀWIURPLWPLJKWDSSHDUOLNHDQLPSRVVLEOHPLVVLRQ2QWKH other hand most Open Source newbies are everything but knowledgeable about legal obligations that come with Open Source. Neither are they likely to comprehend how to truly leverage from Open Source as long as they only consider it as being "free as gratis" code. Both development and management need to learn about it.

Most optimally the use of Open Source ought to be introduced in a company as a coordinated and strategic activity, on which the following pages will elaborate in more detail.

One of the goals could be to get the entire organization seeing how Open Source saves money and improves innovation, to get it to use Open Source software more regularly. But foremost, control has to be established. The Open Source activities need to be agreed and standardized within the organization.

The company introduces policies, procedures, organization and hopefully some training as well WRKDUQHVVWKH2SHQ6RXUFHSUDFWLFHVYHU\PXFKIRUVHFXULQJWKHIXOÀOOPHQWRI OHJDOREOLJDWLRQV that follows with Open Source.

However, introducing Open Source in an organization raises some concerns too. Training all staff on the fundamentals of copyright law and Open Source licenses is costly and might offer a challenge for engineers to grasp. It could be hard to implement and defend the added cost for the necessity of conducting the Compliance work that follows with Open Source.

Awareness on costs related to Open Source arises, both as a threat (potential litigations for license breaches), but foremost as an opportunity (faster development and reduced maintenance). \*DLQLQJWKHEHQHÀWVRI WKHODWWHUZLOORSHQIRUDOORZLQJGHYHORSHUVWRHQJDJHLQ2SHQ6RXUFH communities, including source code contributions, as that will soon will be discovered that is the RQO\IHDVLEOHZD\WRLQÁXHQFH2SHQ6RXUFHFRPPXQLWLHV

Initially, the likely main challenge for management is that Open Source is perceived to raise an unknown legal risk. Management may also perceive that with Open Source unknown technology, ZLWKXQNQRZQHIIHFWVRQWKHFRPSDQ\·VRIIHULQJZRXOGÁRZLQXQFRQWUROOHGDQGZRUVHWKDW YDOXDEOHFRUSRUDWH,QWHOOHFWXDO3URSHUW\PD\ÁRZRXWXQFRQWUROOHG7\SLFDOOHJDOULVNVLQFOXGH copyright and patent lawsuits and to lose control of software and other intellectual property rights. In fact, to handle these matters comes at a bargain in relation to what we gain, compared to continuing the business as usual. We just have to deal with it properly.

Open Source governance policies, processes, tools and organizational structures will be required. Three fundamental processes are essential; an Intake process for legally vetting code that development intends to use, a Compliance process for ensuring that code follows the terms and conditions of Open Source licenses, and a Contribution process for the approval of code to be released to an Open Source community.

> We will need organizational roles such as the Open Source Officer and specific roles for compliance and contribution management.

7KHVHSURFHVVHVZLOOFDOOIRUFUHDWLQJQHZRUJDQL]DWLRQDOUROHVVXFKDVWKH2SHQ6RXUFH2IÀFHU DQGVSHFLÀFUROHVIRUPDQDJHPHQWRI FRPSOLDQFHDQGFRQWULEXWLRQ7KHQHZUROHVZLOOKDYHWR

possess mandates that management might be unwilling to share. An implication that is seldom fully understood is that the current product management has to let go parts of the requirements DQGWKHSURGXFWGHÀQLWLRQ%\LWVYHU\QDWXUHWKHSRZHURYHUWKHSURGXFWGHÀQLWLRQZLOOGULIW toward the engineers and the Open Source communities.

Getting control of the legal matters requires legal and patent counselors to be involved in the software development process. The counseling will be around copyright, patent, IP, and trademark laws. As contributions to Open Source communities become frequent, a larger organiza-WLRQFRXOGEHQHÀWIURPHVWDEOLVKLQJDJRYHUQDQFHERG\DVRFDOOHG2SHQ6RXUFH%RDUG7\SLFDOly such an Open Source Board vets and approves contributions, while considering both business needs and IP protection needs. Such a body would also naturally be mandated to issue corporate policies on Open Source.

To most developers this goes without saying: Integrating Open Source software is no different from integrating any 3rd party software. The software architecture has likely to change to host the Open Source software artifacts. If it's already modular, just with a few cuts in the wrong places, the adaptation will be a smooth job. If it's monolith, a major refactoring of the software is likely required. The Open Source software's APIs must in turn never be changed without approval, to facilitate contributions back to the Open Source community.

To some companies, the Open Source software becomes key elements in both the company's offering as well as its innovation. The companies' engagement in Open Source has to get directed and has to evolve to an Open Source strategy that encompasses development goals as well as EXVLQHVVEHQHÀWV7KH\QHHGDWOHDVWWRLQÁXHQFHWKHFRPPXQLW\WRJDLQVRPHFRQWURORI WKHGHvelopment in the community. The incentives to do this ranges from simply sharing development costs with partners and use common technology, to give the company a competitive edge on its own offering while disrupting the competition. In most Open Source communities the control is i gained by becoming a champion contributor.

Introducing Open Source development sensibly and cross the organization as a strategic and coordinated activity, will likely pay off in a more competitive product offering. Getting state-of-the art Open Source technology to a reduced cost and with a shorter lead-time isn't that bad, after all.

## One more thing

In many large companies, software is considered the property of the team that developed it and is not shared freely within the company. **Inner Sourcing** is the practice of developing and sharing software openly within the company but not beyond (in contrast to Open Source Software).

The companies get many advantages of Open Source software and avoid at the same time IP and license complications associated with open source software con-WULEXWLRQV7KH SULPDU\ EHQHÀWLV KRZHYHUWKH FROODERUDWLYH VSLULW DQG RUJDQL]D-

WLRQDOÁH[LELOLW\WKDWDULVHVIURPWHDPVZKRDUHDEOH to contribute improvements to each other's code. ,QDGGLWLRQWKHUHLVDGLUHFWEHQHÀWLQUHXVLQJFRGH and competence, something that will not only reduce development cost but also increase speed and overall quality.

Volunteer contributors will spring up freely to contribute to interesting projects

There are many other reasons to consider Inner Sourcing. An open environment facilitates increased aware-

ness of the software and helps to break down barriers between teams through the use of common code, tools and methods. Having less duplication of development will cut costs. Volunteer contributors will spring up freely to contribute to interesting projects, which may lead to shorter time-to-market. Since contributions are under large-scale scrutiny, developers get aware of their reputation and motivated to write "good" code.

Moreover, since they are familiar with a standard set of common tools and infrastructure, developers can be more easily transferred to other projects or products. This in turn will reduce time-to-market, as project start-up time can be reduced.

## Get inspired

This scenario has been based on case studies of different companies that have made this journey, to scale with Open Source. Learn from their experiences, what they gained and what they had to overcome.

#### Sharing is caring

A quiet revolution was changing the world for the software engineers at the mobile phone manufacturer Sony Ericsson. An Open Source force of epic dimensions had just been released. This case study is about the manufacturer who embraced a powerful engineering movement and created an Open Source strategy that, although there were initial business EHQHÀWVSULPDULO\HQFRPSDVVHGJRDOVVHWE\WKHGHYHORSHUV

#### A thriving Open Source culture behind the wall

Open Source projects really can't be beaten in terms of development power. This case study gives insights into a multi-national mobile network equipment supplier, which experienced a similarly quiet but powerful Open Source revolution, but behind the company ÀUHZDOOV5HDGDERXWKRZWKHGHYHORSPHQWRUJDQL]DWLRQIRXQGZD\VWRXWLOL]HUHVRXUFHV and created an Internal Source culture.

#### Keeping the doors open

Traditionally, door-opening solutions were about locks and keys. Nowadays, they are still about mechanics but use a lot of electronics and software. It is not just a piece of hardware anymore. The solutions even tap into the industry of services. And there is of course Open Source software usable also in this particular business. Read about ASSA ABLOY, who went from using bits of Open Source software they found, to get really professional about it and implement an Open Source strategy cross their organization.

Sony Mobile's Open Source journey began with general curiosity among developers at Sony Ericsson's development department. This led eventually to an investigation whose results were so convincing that the management took the bold decision to shut down the work on proprietary operating systems and invest wholeheartedly in the Open Source based Android operating system. The new era began in 2010 with the Android telephone Xperia X10, and today all its smartphones are based on the common Android platform.

The company sees a whole host of advantages in belonging to the Open Source movement. First of all, it increases the pace of innovation and development, simply by having a larger number of developers focusing their creativity on a single task. And when someone comes up with a FOHYHUVROXWLRQWKHHQWLUHQHWZRUNKDVDVKDUHLQLWDQGEHQHÀWVIURPLW\$VDUHVXOWHYHU\RQHLV constantly creating new opportunities for everyone else. Without Android, Sony Mobile don't believe it would have existed. More than 85 % of its software is based on Open Source.

It realized early that an Open Source project must be transparent and encourage participation and collaboration. Management had to make Open Source a part of their corporate culture.

## R & D and Legal, hand in hand

Close collaboration with the Legal department has played a central role. A success factor was the early establishment of a "double-command", consisting of its chief strategist for Open Source and a lawyer at its Legal department. The duo has been instrumental in changing the business and mindset throughout the development organization.

The Legal department recognized in the initial stage that Open Source was perfectly solid and valid from a legal standpoint – acquiring Open Source was essentially the same as any other kind of third party software. They also noted that Open Source would become utterly essential for the company's survival from a business perspective. In this way, the Legal department became a key player in persuading executive management that the necessary culture shift not only was possible, but also would be warranted by governance under Legal's supervision.

\$PDMRUFKDOOHQJHZDVWRÀJKWWKHQRWLRQVWKDW2SHQ6RXUFHZDVPDLQO\DVRIWZDUHGHYHORSPHQW concern and something of slight headache to the Legal department. These earlier viewpoints dominated the thinking in Sony Mobile's early days of Open Source. It was seen as OK to use because it was "free of charge". In the last couple of years, as the success of Android unfolded, the mindset changed completely.

Eventually, software developers and lawyers developed mutual trust. The duo translated legal concerns to developers, as well as the other way around, educated Legal on engineering concerns. The resulting trust has also led to executive management being much more daring in taking business initiatives involving openness and collaboration – even when it involves the competition.

## Sony Mobile Open Source Maturity and Strategy model

Today, not only does most of Sony Mobile use Open Source for everyday development, but the company has also established itself as the largest external contributor to Android development.

Recently, it has also taken several initiatives in the marketplace in leveraging Open Source in tilting business to its advantage. It is making progress in achieving position on the higher levels of the Sony Mobile Open Source Maturity and Strategy model, the levels when business concerns come into play.

,WV0DWXULW\DQG6WUDWHJ\PRGHOKDVÀYHOHYHOV7KHÀUVWWKUHHUHSUHVHQWVWDJHVWKDWDUHPRVWO\ driven by engineering and development concerns, whereas the last three levels are more business driven.

Even if the model isn't a tool for scaling into Open Source development, the model has proven to be very effective to communicate where it is and where it aims. It's a model to measure maturity and to set the strategies that works with both developers and management.

7674

#### **Engineering Driven**

#### **Level 1, "Accidental"**

A stage of discovery and early awareness where developers explore and "play around" with Open Source software.

#### **Level 2, "Repetitive"**

A company begins to make use of Open Source software in a governed way, seeing that it can reduce cost and improve interoperability.

#### **Level 3, "Directed"**

Open Source has support from executive management, is incorporated in the product strategy, development aims for champion communities and collaborations widens.

#### **Business Driven**

#### **Level 4, "Collaborate"**

Open Source projects and collaborations are run to achieve both technical and more so business goals which are able to change the market logic.

#### **Level 5, "Prevail"**

The company has developed a fully-fledged Open Source company culture, with full strategic support from the top management, to the extent the company is able to disrupt entire markets.

### Advices & take aways

#### **• Use an Open Source Maturity model**

Understand the level of maturity to drive change, provide a vision and outline a strategy to drive change. Use this extensively as a communication and education tool. Rules and roles regarding project contribution are important – Inner Sourcing projects should start with defining contribution rules and responsibilities.

#### **• Describe the processes for governing Open Source**

This should include how we work, our roles and our responsibilities. The most important processes are intake, compliance and contribution.

#### **• Take benefit from tools**

Take benefit from an Open Source audit tool to ensure compliance and to extract copyleft\* code. Though, it's important to recognize that the main benefit of a tool is to reduce engineers' workload – a tool can't itself replace a lack of policies and processes.

#### **• Educate, educate, educate**

7876

In addition to courses, an everyday present spirit of education should be a part of all interaction. Lead by example, following the three key concepts of transparent, participative and collaborative.

Copyleft (a play on the word copyright) refers to the copyright licensing scheme used when mak- \* ing Open Source contributions.

7977

80

78

Adam is a senior software developer at a big Swedish company in the telecom business. Some years ago, Adam realized that many projects and developers more or less developed the same code. There had to be a way to reuse code and competence across the company. Since he was already familiar with Open Source software he thought a similar approach would also work internally. So he made his own software repository solution available to his colleagues so that they could start sharing code and projects.

The rumor spread and more and more colleagues started to use Adam's tools for sharing code. Later, several teams decided to manage all their internally developed tools by using this repository installation, which still was running on Adam's PC. This was just the start. By the word of mouth and some internal blogging, the initiative spread within the company and grew to such proportions that also other managers realized their organizations depended on Adam's code sharing initiative.

The IT department had at the time licensed a commercial system for code life cycle management but it turned out that the developers rather desired to use Adam's tools. A few attempts were made to get developers to use the commercial solution, but Adam's solution was already too well established within the organization. 5 years later, the Inner Source initiative had grown to a staggering 5.000 projects and 16.000 people. And the only support Adam provided was some short documentation on how to use the tools and some thoughts on Inner Sourcing through his blog.

The company has since long realized that this was a too important and powerful environment to be managed and driven by one person on a small PC. Eventually, they also switched to use a standard commercial system for code sharing and collaboration.

The main reasons the Internal Source initiative grew so strong in the company are the low entry barrier of the tools and the extremely short lead-time for starting up a new project. Developers like it because it is so easy to use and that they instantly get up and running.

,QWHUQDOWRROVDUHYHU\RIWHQÀUVWRXWWREHGHYHORSHGLQDQ,QQHU6RXUFLQJHQYLURQPHQW\$GDP HVWLPDWHVWKDWWKHLULQWHUQDOWRROVGHYHORSPHQWEHFDPHWLPHVPRUHHIÀFLHQWLQWHUPVRI resources, by this initiative. A side effect, but a very powerful one, was that the company also

gained full transparency in development made by third parties, since they as well started to use the Inner Sourcing environment.

A key success factor behind introducing Inner Sourcing was the corporate culture. The teams DUHIDLUO\DXWRQRPRXVDQGZHOOHPSRZHUHGWRGHÀQHDQGXVHWKHLURZQPHWKRGVDQGZD\VRI working. Adam states that to succeed with Inner Sourcing, the company culture has to be built on trust and empowerment of teams and individuals.

Even though tools still are the most common Inner Source projects within the company, also a few commercial products rely on Inner Sourcing. Adam is convinced that Inner Sourcing will be instrumental to tackle future capacity and time-to-market challenges.

### Advices & take aways


8280

CASE STUDY / Co-develop in a community

One very clear example of a company that has moved from hardware-based products to software-intensive solutions is ASSA ABLOY. This company is a leading manufacturer in door-opening solutions and a market leader in Europe, North America, China and Oceania. The company was formed in 1994 through a merger of ASSA in Sweden and Abloy in Finland. Since then, it has grown from a regional company to an international group employing a workforce of over 46.000.

Traditionally, door-opening solutions were about designing and manufacturing locks and keys, and as such, this business is very much dependent on the price and availability of steel as the raw material. While steel and mechanical solutions are still important, most of the costs of the company's solutions are spent on software development. Modern door opening solutions involve a considerable amount of electronic circuits and software to control them. Furthermore, door-opening solutions now also start tapping into the industry of services. The days where a lock was just a piece of hardware are over.

ASSA ABLOY has developed software for decades for its back-end door-lock systems and Open 6RXUFHLVQ·WDQHZWKLQJIRUWKHP,QGHHG\$66\$\$%/2<ZHUHZHOODZDUHRI WKHEHQHÀWVWKDW Open Source Software can offer, such as reducing development time, increased security (as some of the relevant OSS components are thoroughly tested), and high quality products. However, there was never a company-wide strategy or policy around Open Source. As is common in many FRPSDQLHVGLIIHUHQWHQJLQHHULQJWHDPVÀUVWEURXJKWLQ2SHQ6RXUFHLQDQXQFRQWUROOHGZD\\$V the company realized the increasing strategic importance of Open Source, the company started investigating tools and policies for using Open Source more consistently. This new task was assigned to ASSA ABLOY's Shared Technologies division, which is responsible for developing common software assets and scouting new technology.

ASSA ABLOY Shared Technologies understood that becoming familiar with the various Open Source licenses was key in order to become compliant. To that end, a tool was used that automatically VHDUFKHVDQGLGHQWLÀHV2SHQ6RXUFHVRIWZDUHLQWKHLUFRGHEDVH+RZ-HYHUVRRQWKHFRPSDQ\UHDOL]HGWKDWPHUHO\XVLQJDWRROZDVQ·WVXIÀcient to engage with Open Source products. Engaging in Open Source also requires developing an understanding of the Open Source software lifecycle management, and how to align this with the company's internally GHYHORSHGVRIWZDUH\$QHZSROLF\ZHUHQHHGHGEHIRUHPDNLQJVLJQLÀFDQWLQYHVWPHQWVLQWRROV

ASSA ABLOY took a number of steps to establish an Open Source engagement policy. First, the company sought advice from Open Source consultants to be better informed about the conse-TXHQFHVRI XVLQJ2SHQ6RXUFHVRIWZDUH6HFRQGSULRUWRUROOLQJRXWWKHQHZO\GHÀQHGSROLF\DQG process, all engineers, project managers and line managers in the Shared Technologies division were enrolled in a training program on these issues.

7KH FRPSDQ\·V SURFHVV DQG SROLF\ GHÀQHV D VWUXFWXUHGZD\WRPDQDJH GLIIHUHQW2SHQ6RXUFH software, which includes the following key processes:


A key challenge was really the absence of a company-wide Open Source policy. It was very dif-ÀFXOWWROHYHUDJHDQGJHWFRQWURORI 2SHQ6RXUFH6RIWZDUHZLWKRXWLW\$QRWKHUFKDOOHQJHRQH

Getting the teams more involved in communities is truly a challenge

8684

shared with many other companies, is how to more actively engage with Open Source communities. Even though the company management encourages participation in communities, the development teams are still mainly users, not contributors, of Open Source software. Achieving this is truly a challenge.

\$66\$\$%/2<6KDUHG7HFKQRORJLHVLVFOHDUO\RQDMRXUQH\ZKHUHLWQRWRQO\VHHVWKHEHQHÀWVIURP using Open Source in their products but it also sees the value in actively engaging in communities, in order to actively participate in the evolution of Open Source products that it has a stake in.

This scenario is about how to go from "only" creating product value from an Open Source community to drawing comprehensive gains from orchestrating an own ecosystem.

89

The ultimate Open Source strategy is to go beyond the communities and create an ecosystem that becomes the business and not just supports the business. At its furthest implementation, the ecosystem has disrupted the entire market logic and became the helm of the market. Google and Apple are great examples of companies that made exactly this. Google's Android is basically nothing but a collection of 60 to 70 Open Source software packages. Similarly, Apple's OS X and iOS are highly dependent on Open Source (BSD Unix and Web Kit among others). The key aspect of their success has been their ability to join together Open Source communities and blend differentiating (often proprietary) parts of their products with commodities offered as Open Source.

Open Source is a game changer to the business, since parts that are contributed as Open Source also gets commodities and brings down the value of the offering. The business drivers are mostly a product of the change in the business model. Typical goals that companies aim for are basically to:


7RDFKLHYHWKLVUHTXLUHVJUHDWÁH[LELOLW\LQFUHDWLQJQHZUHYHQXHVWUHDPV7KH\FDQEHEDVHGRQ an extended business model (when alternative revenue is collected from something related to the core offering, e.g. a service fee), an indirect business model (when revenue is mainly collected through a device or a hardware offering) or an asymmetric business model (when revenue is collected from a source unrelated from the core offering). An example of the latter is Google's \$G6HDUFKEXVLQHVVWKDWEHQHÀWVIURPSURYLGLQJ\$QGURLGIRUIUHH

2SHQ,QQRYDWLRQ2,LVWKHGRPLQDQWPRGHORI JDLQLQJH[WHUQDOEHQHÀWVDQGJHQHUDWLQJVSLQ offs from openness.

Illustration based on picture from presentation of Open Business Models by Henry Chesbrough 89

The key desired abilities we strive for – to be able to reach, create and orchestrate an Open Source based ecosystem, an ecosystem that also could be described as a community of communities – require a collaborative business model.

However, a journey like this can only start once a company's use of Open Source can be said is being directed, when the company has gained such support from the executive management so the use of Open Source software is paramount of the product management. (See the chapter **Co-operate in a community**.) At this stage the company is well versed on the engineering and legal aspects of Open Source. The company's knowledge level on Open Source is satisfying to the extent that directives and policies are relaxed and some automation of the governance processes has been introduced. Moreover, Open Source technologies have become such a valuable HOHPHQWRI WKHRIIHULQJLWLVQHFHVVDU\WRLQÁXHQFHWKHFRQWURORI WKH2SHQ6RXUFHGHYHORSment. The product offering itself has also gone through a transformation. Fundamental is that it has a modular architecture, but more, it's likely that the product is connected to the Internet, preparing the offering to be extended by cloud-based services.

9290

Although the entire idea with building an ecosystem is to scale the business, it can still be a challenge for the management to recognize how Open Source as a phenomenon can be used as a business tool. The management will have to explore radically different market logic, and in this, they have to fundamentally question what really is the company's core offering and how alternative revenue streams then can be created. The cemented truth that "proprietary Intellectual Property is paramount for a company's success" will often be proven wrong.

Most essentially comes with Open Source a participatory culture. Customers are moving from being passive receivers of purchased solutions to actively involve themselves in the development of the product offering itself. Many companies have created Developer Programs to catch and nurture WKLVNLQGRI FXOWXUHRSHQLQJXSIRUFXVWRPHUVWRLQÁXHQFHWKHGHYHORSment of the product offering.

#### A Developer Program is very often seen as the seed of an ecosystem.

7REHWWHUUHÁHFWDQGVXSSRUWWKHWUDQVIRUPDWLRQWRDKLJKO\FROODEorative business model, a more supporting and coaching leadership style is highly promoted. The business lends itself to be run by a ÁDWQHWZRUNRULHQWHGDQGVHOIPDQDJHGRUJDQL]DWLRQZKLFKEHWWHU UHÁHFWVDQHFRV\VWHPVWUXFWXUH

7KHFXUUHQWSURGXFW0DQDJHPHQWZLOOREYLRXVO\EHXQGHUÀUHVLQFHPXFK RI WKHSURGXFWGHÀQLWLRQZLOOUHVLGHRXWVLGHWKHRUJDQL]DWLRQ,W·VLPSRUWDQW though, that the role for the product Management is adapted to envision IXWXUHRIIHULQJVUDWKHUWKDQGHÀQHWKHSURGXFWLQGHWDLODVWKHODWWHUZLOOGULIW towards crowd-based requirement engineering set-up in the ecosystem.

The Legal department will deepen its collaboration and start building legal frameworks for novel offerings, as part of the company business development.

+RZHYHUGLIÀFXOWWKHWUDQVIRUPDWLRQRI PDQDJHPHQWPLJKWDSSHDUDPDMRUJURZLQJSDLQZLOO be to recruit the necessary talents in order to build the ecosystem. This accounts in particular for cloud-based services and the necessary support systems for the new business it will offer. Those people are currently amongst the most sought after in the industry.

7RVXPPDUL]HVRIWZDUHFRPSDQLHVFDQEHQHÀWIURPFUHDWLQJDVRIWZDUHHFRV\VWHPEDVHGRQ shared Open Source, including partners, customers, end users and sometimes competitors. The latter is not too far-fetched as many competitors may be entangled in the same Open Source GHYHORSPHQWEHLQJ5 'SDUWQHUVLQDQLQGXVWU\ZLGHFROODERUDWLRQ6XFKFROODERUDWLRQVLJQLÀcantly raises the market entrance bar for competitors with proprietary offerings – who would have costlier development and maintenance as well as the burden of alone having to prove its value on the market.

## Get inspired

This scenario has been based on case studies of different companies that have made this journey, to scale with Open Source. Learn from their experiences, what they gained and what they had to overcome.

#### Pushing the boundaries

There are companies that relies on cloud technology infrastructure more than others. If they also happen to include gigantic data transfers in their offerings, it's not unlikely that WKH\ZLOOKDYHDYHU\FORVHORRNLQWRWKHHFRV\VWHP1HWÁL[KDYHFUHDWHG5HDGDERXWWKH company that employs more than 700 engineers that more or less gives away everything WKH\FUHDWHMXVWWRNHHSWKHEXVLQHVVÁRXULVK

### Servitization

Open source and ecosystems are almost always the preferred way when scaling a business from products into services. Take again Netflix, who provided a DVDby-mail service before creating their video streaming service. They likely made a transformation such as the one the Servitization scenario describes. It's the next chapter in this book, "Add supplementary services." Read it as well!

9896

)RUWKHODVW\HDUV1HWÁL[KDVDFFRXQWHGIRUPRUHWKDQDWKLUGRI WKH,QWHUQHWWUDIÀFVWUHDPLQJ LQWR1RUWK\$PHULFDQKRPHVHYHU\QLJKW7KDW·VPRUHWKDQWKHFRPELQHGWUDIÀFRI WKHWUDLOLQJ contenders such as YouTube, Hulu, Amazon, and iTunes.

\$WDQ\PRPHQW1HWÁL[GUDZVXSRQWRVHUYHUVUXQQLQJLQ\$PD]RQGDWDFHQWHUV The computers handle customer information, video recommendations, digital rights manage-PHQWHQFRGLQJRI YLGHRÀOHVLQWRGLIIHUHQWIRUPDWVDQGPRQLWRULQJWKHSHUIRUPDQFHRI WKH systems. When a new device as for instance an upgraded game console or a smartphone comes DORQJ1HWÁL[XVHVWKRXVDQGVRI H[WUDVHUYHUVWRUHIRUPDWPRYLHÀOHVDQGWRVHUYHWKHQHZXVHUV 1HWÁL[KDVDUHQRZQHGUHSXWDWLRQIRUSXVKLQJFORXGFRPSXWLQJDQG\$PD]RQ:HE6HUYLFHVWR its limits.

)URPWKHYHU\VWDUW1HWÁL[KDVEHHQIRUFHGWREXLOGPXFKRI WKHVRIWZDUHIURPJURXQGXS Since they rely on Amazon data centers, their 700+ engineers focus on tools that for instance DXWRPDWHWKHZD\LQZKLFKWKRXVDQGVRI FORXGVHUYHUVDUHVWDUWHGDQGFRQÀJXUHG/LNH\*RRJOH )DFHERRN/LQNHG,QDQG7ZLWWHU1HWÁL[GHSHQGVODUJHO\RQ2SHQ6RXUFHIRUPXFKRI WKHVRIWware that underlies their operations. The companies compete in fact on who's paying most for the most clever engineers, to give away their outcome so that others can build on top of it.

Giving away their technical wizardry for free and to rely on 4.000+ volunteer programmers PDNHVSHUIHFWVHQVHWR1HWÁL[\$WWKHHQGRIWKHGD\WKH\ZLOOJDLQIURPPRUHUREXVWFRGHWKDW has been infused with bleeding-edge innovation.

Together, these companies forge the cutting-edge Open Source cloud computing technology WKDWPDLQVWUHDPFRPSDQLHVZLOOXVHLQWKH\HDUVWRFRPH,WLVHVVHQWLDOWR1HWÁL[WRKDYHDOHDGing role in streaming video cloud technology to maintain their forerunner market position. They have to accept that their competitors – old ones working with cable technology as well as new RQHVZRUNLQJZLWKWKHZHE²LQDÁLFNFDQEHFRPHWKHLUSDUWQHUV

7RHQVXUHWKHFDVH1HWÁL[KDVFUHDWHGDJUHDWDUVHQDORI RSHQVRXUFHFORXGFRPSXWLQJWHFKQRO-RJ\7KH\KDYHWRROVWRLQVWDOOSUHVHWSDFNDJHVRI VRIWZDUHRQ\$PD]RQVHUYHUVWRUHFRQÀJXUH them and to test them without causing any downtime. The so-called Simian Army, another set

RI DSSOLFDWLRQVSXUSRVHIXOO\WU\WRZUHDNKDYRFRQWKHLULQIUDVWUXFWXUHLQDELGWRÀQGKROHVDQG performance problems. Chaos Monkey, for instance, simulates small outages by randomly turning services off, while Chaos Kong takes down an entire data center.

(YHQWXDOO\1HWÁL[ZDQWVWRXVHDQRSHQVRXUFHSODWIRUP,QVWHDGRI UHOHDVLQJFRROEXWGLVSDUDWH projects, the company wants to put together a cloud management system that software developers can poke and prod and advance. A platform would provide an opportunity to widen the offering beyond the core business.

,QWHUHVWLQJO\HQRXJK1HWÁL[·V2SHQ6RXUFHVWUDWHJ\LVQRWRI DQ\SDUWLFXODUROGDJH,WDOOVWDUWed in 2011. Only a few years later, they had built a bustling community and ecosystem. Today, 1HWÁL[LVFU\VWDOFOHDURQWKHLUFRUSRUDWHYLHZRQ2SHQ6RXUFH,WLVQRWRQO\DPHDQIRUGHYHOopment – it's a strategic weapon for their business. We should expect the "More to come, stay tuned!" screen on their business outlook.

### Sources and more reading

Netflix, Reed Hastings Survive Missteps to Join Silicon Valley's Elite, 2013, www.businessweek.com Netflix Announces \$100,000 in Prizes for Coders, 2013, www.businessweek.com Netflix and YouTube Dominate Online Video. Can Amazon Catch Up?, 2013, www.businessweek.com NetflixOSS Meetup, 2013, www.slideshare.net techblog.netflix.com

## Netflix Open Source software downloads

**netflix.github.io/#repo**

SCENARIO / Servitization

102

100

A service is the means o<sup>f</sup> delivering value to customers by facilitating outcomes customers wan<sup>t</sup> to achieve without the ownership o<sup>f</sup> specific costs and risks.

ITIL\* defines service this way. It basically means that the customer gets something they want without having to bother about the supplier's efforts to provide it.

Services are stand-alone offerings, but could also be offered with a product as a supplement.

To get to the grips with servitization, see also:


ITIL 2011, (Information Technology Structure Library) \*

103

## **servitization [ ser · vi · ti · sa · tion ]**

In essence servitization is a transformation journey - it involves companies developing the capabilities needed to provide services and solutions that either supplement or replace their traditional product offerings. Recent technological advances such as cloud computing, big data analytics, mobility and social media have enabled the servitization trend.

Servitization is used when a company introduces a service offering as a means to further satisfy WKHLUFXVWRPHUV·QHHGVWRHQKDQFHSURÀWDELOLW\WRJDLQDFRPSHWLWLYHDGYDQWDJHRUWRDYRLGFRPpeting with low-cost countries on a cost alone basis. The theory suggests there are three levels of product-to-service transformations, but there are no clearly delineated boundaries. It's rather a PDWWHURI KRZ\RXUYDOXHSURSRVLWLRQLVGHÀQHG

To completely replace a product with a service requires a long-term investment.

In this case there is no product or owner. The service is consumed at the same time as it's delivered.

Companies that made this journey can for instance be found in the entertainment industry.

Example: Netflix

A middle-road approach is to keep the product and transform the business model to be subscription-based.

The owner of the product is now the service provider. Companies that made this journey can be found where buying the product requires a substantial investment.

Examples: Rolls-Royce with its Power-by-the-hour aircraft engine program and Xerox printer service.

Least complex is to keep the product and purchase-based business model, but add supplementary services such as maintenance and premium programs.

The owner of the product is in this case still the customer. Numerous businesses successfully adopts this model.

Examples: Ericsson offers maintenance of their telecommunication equipment. Turning a legacy product business into a cloud-based service business has become the Holy Grail of the software industry in recent years. Being able to provide customer value by making services that for instance use data from the billions of Internet of Things sensors, turns out to be a money-maker. It's not that easy, of course. You have to make sense of the data, turn it into knowledge and meaningful actions. Parking place sensors are practically useless if you can't come up with a clever way to help your customers TXLFNO\ÀQGDIUHHSDUNLQJSODFH7KHUHDUHQXPHURXVH[DPSOHVRI FRPSDQLHVWKDW have successfully made the journey to replace their products with services and by that LQFUHDVHGWKHLUSURÀW<HWLW·VIDUIURPDGRQHGHDOZKHUHDVPDQ\DOVRIDLO0RVWFDsualties are usually claimed during the transformation phase. Learning from the pitfalls DQGKRZVXFFHVVIXOFRPSDQLHVPDGHLWVLJQLÀFDQWO\LQFUHDVHDFRPSDQ\·VFKDQFHWR succeed. The solution described in this chapter has proven to be fruitful.

Consider for a minute the dynamics within the management group. Who gets to talk most on the management group meetings? This will change. Substantial amount of time and resources that are currently allocated to track and report development and manufacturing will decrease to an absolute minimum. Sales, or rather the new function that sales will have to become, will get the most attention. Expect clashes since not everybody will be able to free themselves from their previous roles and traditional ways to run the business.

Being able to offer a service is a huge opportunity that can completely change your business mod-HO'RQ·WWKLQNWRRORQJDERXWLW6HWWLQJXSDSURÀWDEOHVHUYLFHWDNHVWLPHDQGLW·VQRWXQOLNHO\WKDW your competitors have already started. Agility will turn out being your key ability.

Regardless where you aim in your scaling effort, it cannot be emphasized enough how important it is to start in the management team. First priority is to change everybody's point of view, to stop gazing at the Gantt chart and

instead seeing the customers.

Another priority, and indeed a great challenge, is to develop a scalable, UHSHDWDEOHDQGSURÀWDEOHEXVLQHVVPRGHO,QWHUPVRI FUHDWLQJLWWKHUHLVQ·W really any difference between an established product business that wants to start a service and a start-up business. They have an idea of a service business but the value proposition hasn't been carved out entirely. Both have to ask and challenge the same questions.

7R VXSSRUWLQÀQGLQJWKHDQVZHUVPDQ\ VXFFHVVIXOZHEEDVHGFRPSDQLHV²LQFOXGLQJ6SRWLI\ Dropbox, Airbnb and IMVU – use the customer development method described in the book "The Lean Startup".**\*** It's a very good start, no matter from where you come.

Customers have to get value day after day, month after month, to stay as such. They have very high demands on availability. When at least 99.9% availability is expected on a normal service, there's absolutely no room for temporary glitches. The ITIL 2011 has shown to be a great source of knowledge to support how to get there. Study in particular the Service Management guidelines.

How do you provide a service that customers willingly pay for month after month? You have to get to know them and demonstrate that your service adds value to every one of them, every day. The technology gets secondary – the customer experience becomes primary. What are their needs? Understanding your customers and their behavior will be key. How do they use your service? Fortunately, it's much easier to monitor customer behavior when they're using services than it is when they're using products.

A huge advantage with software services is that you can prototype improvements and new features in a small scale without having to make major investments. The service can grow as the business grows and your customers FDQEHQHÀWIURPQHZIXQFWLRQDOLW\LQVWDQWO\)XUWKHUEHLQJDEOHWRXVHOLYHXVDJH data and prioritize development that improves the service, makes this advantage even more valuable.

The development work lends itself to be carried out in an iterative way, to create a so-called

minimum viable product every week, or even every day. There are Agile development techniques such as Continuous Delivery, A/B testing and DevOps**\*** that perfectly support this way of working. An iteration would only comprise a few of the highest ranked work items in a priority-ordered list, called the backlog.

After having provided the new features to your customers, you can measure, analyze and improve them. If a feature doesn't live up to the customer's expectations, the design has to be improved. New features are not taken away from the developer's backlog until the customers show, either through surveys or logged behavior, that everything works nicely.

#### **Simply put – fail fast, learn fast, and improve fast.**

This is a never ending cycle of making a hypothesis about a new customer feature, building the minimum viable product, looking into how it's used, learning from it, making a new hypothesis, building, releasing, analyzing and learning, and on and on. There will always be high time to improve either the business model or the service.

Experiences have shown that the companies that have created small, autonomous teams that work as start-ups are the ones that also are the most successful. Many of them work according to the customer development methods described in "The Lean Startup".

> A practice that emphasizes the collaboration and communication \* of software developers and IT professionals

The challenges are plenty fold, as can be expected. While many companies are successful, many DOVRKDYHGLIÀFXOWLHVLQVHHLQJWKHEHQHÀWV0RVWFRPPRQO\WKH\H[SHULHQFHSUREOHPVZLWK


The pit holes along any servitization journey are numerous and failing to get around them will inevitably jeopardize the transformation process. But, there's no reason to be discouraged. Despite a massive change in business and ways of working, the servitization journey is proven to be truly worthwhile. Research shows, for instance, that successful service providers clearly gain:


The servitization canvas helps to avoid making old mistakes in getting these gains.

## Get insights

This scenario has been based on case studies of different companies that have made this journey, to scale with Servitization. Learn from their experiences, what they gained and what they had to overcome.

#### Adding Internet to things

Read about the company that boosted their B2B sales by spicing their lawnmowers products with IoT.

#### Boosting product sales by services

Learn from the company who aimed too high with a worldwide download service for the man on the street.

## One more thing

When scaling a software organization through servitization, the software architecture has to be adapted.

The chapter **First things Àrst** describes a canvas that was created for this purpose, as a guide on how to improve the software's internal structure.

It is furthermore strongly recommended to work in an Agile way. Find canvases for Agile development in the chapters **Pump up the volume**, **Deliver 24/7** and **Agile and Disciplined**.

#### CASE STUDY / Add supplementary services

114 112

## **Adding Internet to things**

Husqvarna is a global manufacturer of lawn and garden equipment, offering products varying from chainsaws to lawn mowers. They are now in a shift from offering mechanical products to also produce products having electronics and software. An increasing amount of unique product IHDWXUHVQRZEXLOGVRQVRIWZDUH7KHVKLIWVWDUWHGLQWKHPLG·VZKHQWKHÀUVWURERWLFODZQ mowers were launched, but until 2016 the products had virtually no connectivity. It's connectivity that makes the machines able to communicate and possible to integrate with customer services. Husqvarna Fleet Services is such a service.

The hardware of the system consists of a sensor that is mounted on the machine, an operator tag that is carried by the person who uses the machine and a base station that is placed in the FXVWRPHU·VJDUDJH7KHVHQVRUFROOHFWVGDWDDERXWKRZWKHPDFKLQHLVXVHGRXWRQWKHÀHOG,W also keeps track of who is operating the machine. When the machine is back in the garage, the data is collected and sent through a gateway to Husqvarna Fleet Services cloud data services. Operators, managers and technicians at the companies that subscribe to the service can then get information such as vibration levels, service needs and machine usage based on collected data that has been fused with data from other Husqvarna data sources.

Husqvarna Fleet Services started in 2007 as an idea in the After-sales department, basically to RIIHUDVHUYLFHWKDWKHOS&RPPHUFLDO/DZQDQG\*DUGHQFXVWRPHUVPDQDJLQJWKHLUÁHHWRI +XVTvarna products. Until 2011, all development was run by After-sales as a study on a very limited budget. To create the proof-of-concept, they cooperated with an external technology company. From that point, in 2011, the project gained increasing support from the R&D department. In \$XJXVWDEHWDYHUVLRQRI WKHVHUYLFHZDVÀQDOO\UHOHDVHGWRDOLPLWHGVHWRI FXVWRPHUV\$ new R&D department was started in December, with the responsibility to host all Husqvarna service products, one of them being the Husqvarna Fleet Services. A group wide decision forum IRUSURGXFWFRQQHFWLYLW\DQGDGHSDUWPHQWIRUPDUNHWLQJDQGVDOHVZDVDVZHOOFUHDWHG7KHÀUVW limited commercial release of Husqvarna Fleet Services was released mid-2016.

Gaining competitive advantage

Customer

expectations

Husqvarna's products were becoming smart devices – but this wasn't enough: Husqvarna's organization had to become smarter, too. As a hardware-oriented company, Husqvarna had initially very limited software and system development capabilities. An important step was to form an R&D department that could develop new services. The IT organization had to create a new department as well, with responsibility to build and operate the IT infrastructure needed for the service. They worked independently from the original parts of the IT department. The IT organization had to work in a Bi-modal way, so to say in one speed for the original IT work and in another speed for the rapidly moving services developed by the DevOps teams.

Husqvarna saw the demand from the market, the need for a product like Husqvarna Fleet Ser-YLFH7KH\LGHQWLÀHGDPDUNHWWUHQGVXFKDVGLJLWDOL]DWLRQDQG,QWHUQHWRI 7KLQJVDQGQRZWKH organization is changing accordingly. What originally started as an experiment is now reshaping the identity of the entire company – it's a transformation from a traditional, product-oriented manufacturing business to a business where services lead the way towards the future. It has taken a long time to get where they are now, about nine years. But the idea of introducing services was a good one, an idea that eventually made the whole company line up and work towards a common goal. As this is written Husqvarna is still on the journey, but its chances to succeed in its servitization is considered very good.

116 114

This case study is about how the mobile phone manufacturer Sony Ericsson went from only offering physical products to also include a music listening service called "PlayNow plus". Sony (ULFVVRQUHOHDVHGWKHLUÀUVW:DONPDQSKRQHLQ,WZDVWKHZRUOG·VÀUVWSKRQHDLPHGIRU listening to music. The PlayNow plus service was basically introduced to increase sales of mobile phones, but also to be a step to keep the lead in the global music listening business. The service GLGQ·WKDYHWREHSURÀWDEOHRQLWVRZQ

118 116

tening business

7KHFDVHVWXG\FRQÀUPVWKDWWKHFXOWXUHWKHXQGHUVWDQGLQJRI KRZWRVHOOWKHVHUYLFHDQGKRZ QHZZD\VRI ZRUNLQJDUHGHÀQHGDUHWKHWKUHHPRVWFRPPRQFKDOOHQJHVZKHQLQWURGXFLQJVHUvices. Atos Consulting\*DOVRFRQÀUPHGWKHVHÀQGLQJV7KHWUDQVIRUPDWLRQUHTXLUHVVHYHUDOVWHSV including adjustment of KPIs, redesigning processes, aligning management, organization (not least the IT department), people, and culture. It is virtually impossible to shift the entire organization at once. The servitization transformation is a journey and not a one-time change.

Sony Ericsson was a product company with very little experience in delivering services. The VHUYLFHRUJDQL]DWLRQH[SHULHQFHGKXJHGLIÀFXOWLHVLQERWKFKDQJLQJWKHFXOWXUHRI 6RQ\(ULFVson as educating personnel in what it meant to deliver a service. Part of the explanation is that DOPRVWDOOVDOHVFDPHIURPVHOOLQJPRELOHSKRQHVQRSURÀWZDVH[SHFWHGIURPWKH3OD\1RZ plus. Sony Ericsson continued to focus on product development and also expected the PlayNow team to align with their long-lasting product development cycles. With customers expecting new functionality continuously, the way the service developed and how it was operated was far from optimal.

The IT organization did not have any prior experience of external customer facing applications. 'XHWRVHFXULW\UHDVRQVWKHVHUYLFHKDGWREHKRVWHGEHKLQGWKHFRPSDQ\ÀUHZDOOV7KH,7RUJDQLzation simply didn't understand the implications of this decision. This led to enormous problems, such as having to shut down the service during weekends during the regular maintenance of the internal IT systems. A service like PlayNow plus must be available 99.9% of the time, if its users should even think about using the service as their main way to listen to music.

While cultural problems were among of the biggest internal hurdles to overcome, communicating the service business model to potential customers became their biggest external problem. The service organization lacked basic knowledge about the market. Two questions they didn't ask were:


The PlayNow plus service was launched to the Nordic countries in August 2008. As a reference, Spotify was launched shortly after, in October. PlayNow plus offered DRM free (without digital rights management) MP3 tracks, while Spotify offered a streaming service. They offered basically the same service, but in two completely different ways.

6SRWLI\UHSRUWHGDORVVRI PLOOLRQLQ%XWDVLWKDGDORQJWHUPJRDOWREHSURÀWDEOH it could take the loss for an extended amount of time. PlayNow plus was never considered to EHDIXWXUHSURÀWPDNHUQRUZDVLWVHHQDVDQLQYHVWPHQW7KHVHUYLFHZDVWHUPLQDWHGLQ as a decision to cut costs.

Services are SURšWDEOHUHYHnue streams

120 118

**III** The scaling Agile model is for companies that want to start working with Agile on a larger scale. The complete model describes scaling in three domains: value stream, offering and size.

> **I**This chapter focuses on the offering and value stream domains.

**II**

**V**

**V**

**I**

**X**

**II**

**V**

**I**

123

### About Agile

During the 1990s, a number of lightweight software development methods evolved in reaction to the prevailing waterfall software development methods. They all follow the principles that were outlined in the Agile manifesto 2001.**\*** There are many agile development methods now. Most of them promote teamwork, collaboration, and process adaptability throughout the product development life cycle.

Agile development methods break product development work into small increments allowing frequent feedback on value and quality.

Scaling Agile is a concept that helps you spread and consolidate the agile philosophy throughout the organization to follow the Agile Manifesto that says that "our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

This type of change is often very thorough and includes a review of leadership, gov-HUQDQFHDQGGHFLVLRQPDNLQJVWUXFWXUHVDVZHOODVWKHFKDQJLQJUROHVDQGPRGLÀHGRU-JDQL]DWLRQ7KHFKRLFHGHSHQGVRQWKHFRPSDQ\·VGULYHUV²YDOXHFUHDWLRQHIÀFLHQF\ innovation, or something else.

## Companies that succeed with the scaling Agile process are characterized by three things:

#### **Co-located, cross-functional teams**

The teams contain all the necessary competence to deliver value, for instance developers, testers, architects and business representatives. The teams are as well FRORFDWHGWRJHWHIÀFLHQWIDFHWRIDFHFRPPXQLFDWLRQ

#### **Delegative style leadership**

Management must understand the agile values and make it necessary to implement the planned change. Agile methods also requires that the leadership focus on teams in a very different way than the traditional command and control style. A more delegative and cooperative leadership style is needed.

#### **Iterative approach with short feedback loops**

Technology and infrastructure will enable fast feedback and fast, frequent release cycles. At the end of each iteration, stakeholders as well as customers review the progress and re-evaluate priorities to optimize the return on investment and to ensure alignment with customer needs.

Customer value

Innovation

## Scaling agile

Many large companies struggle with timely delivery of products and services that customers really want. While agile methods are widely adopted, a key challenge is to scale the agile approach to the corporate level. While software development teams may follow agile methods such DV6FUXPFXVWRPHUVPD\QRWEHQHÀWLI RWKHUNH\SDUWVRI WKHRUJDQL]D-

tion are still operating based on a waterfall philosophy. Adoption of Lean Thinking and Enterprise Agile philosophies that focus on end-to-end systems thinking is still OLPLWHGDQGWKHVRIWZDUHLQGXVWU\KDVDORQJZD\WRJRWRDFKLHYHWKHWUXHEHQHÀWV of being agile.

There are three reasons why a company would want to scale up agile to the whole organization:


Everything is sprung out of the need to become stronger, to innovate better products and to better differentiate between products.

**The scaling objective (what we want to become) is in the theory called Scaled Agile. Scaling Agile is the transformation that gets us there, towards the Scaled Agile. There is no actual end state, since the market, technical trends and so on vary over time.**

In this scenario we deal with two levels of scaling objectives. The primary objective is to scale the value stream – this is what being Agile is all about, to take full responsibility from idea to payment, LHWRKDYHDZRUNLQJHQGWRHQGÁRZZLWKLQWKHRUJDQL]DWLRQ7KHVHFRQGDU\REMHFWLYHLVWRVFDOH the offering – this is to scale stand-alone products or services. Each offering will have its own value stream and perform as a "mini-company" in its own.

It's a challenge to get everybody on-board, getting everybody to accept full responsibility. Every person in the development process needs to understand the business, how the market evolves, and what competitors are up to. From what they know, they have to create a Minimum Viable product (MVP). This is a central concept in agile and lean philosophies, to not implement too little, not too much, but just about what is takes to keep the customer ahead and the competition behind.

Once a company has established an agile value stream, it becomes easier to differentiate between various products and services. Of course, it's not as simple as just replicating teams, or worse, assigning the same team for several product offerings. Scaling in the product domain, creating new products and services based on existing assets, usually means that the software architecture and supporting systems have to be adapted. Introducing continuous portfolio planning and project visualization will become of utmost importance to remain agile.

## Delivering continuously

As innovation and coding can be dealt with by introducing agile methods, so can test, integration, build, and delivery practices. How about eliminating all manual work, developing an ability to deliver a change to the customer within hours, or even minutes? How about being able to deliver bug À[HVVRRQDIWHUWKH\DUHUHSRUWHGZLWKRXWFDXVLQJDQ\GRZQWLPHLQGHYHORSPHQW"7KHVROXWLRQWR this is Continuous Delivery. Its practice is rapidly becoming very popular among major software and service suppliers such as Microsoft, Ebay, Amazon, Facebook, and Google. In particular products that are deployed through the cloud are very amenable to this approach.

Continuous Delivery helps in becoming more receptive and responsive to customers' needs. To continuously get new features might not be what every customer wish, but many would even love WRJHWHDUO\DFFHVVWRVHPLÀQLVKHGIXQFWLRQDOLW\WRJHWDFKDQFHWRJLYHIHHGEDFNZKLOHIHDWXUHVDUH VWLOOLQGHYHORSPHQW)HDWXUHWRJJOHVWRHQDEOHXQÀQLVKHGIHDWXUHVDUHIRUWKLVSXUSRVHDYHU\LPportant concept within Continuous Delivery. Another important concept is to implement essential features in two variants and using A/B testing to determine which variant works best.

Continuous Delivery depends on a delivery pipeline – a series of steps that a product's source code has to go through to be delivered. To establish such a pipeline isn't trivial and doesn't happen over a night. Apart from the very challenging task to automate delivery to customers, the biggest challenge is to automate testing. Constructing a comprehensive test suite that is good enough takes a lot of time, and so does the implementation of the required automation tool support, which is an instrumental and challenging part for any organization. To continuously allow all changes that pass all tests to be deployed to customers requires a mature and stable team that embraces a culture of FRQÀGHQFHKXPLOLW\DQGFDSDELOLW\(YHU\WKLQJERLOVGRZQWRVRXQGPDQDJHPHQWWRHQFRXUDJH an altruistic mindset and culture, and to build the trust that is needed for such a culture.

## Maintaining stability

When scaling IT systems in an established company, there is usually a need to balance the stability LQOHJDF\V\VWHPVZLWKWKHÁH[LELOLW\LQWKHLUDJLOHEOHHGLQJHGJHRIIHULQJ7KHZRUNZLWKFRUHWHFKnologies and infrastructure is deliberate, consensus-driven, and slow moving, and so it has to be. The cash cow must not be rushed. The most novel products and services, on the other hand, may be highly experimental and may require more frequent updates in the technology infrastructure.

This is called Bimodal IT, the concept of having two distinct IT methodologies in the same company. The Agile IT team handles the growing needs of the business while the core IT team handles day-to-day business technology functions. The Agile IT team can quickly roll out fast evolving technologies while the core IT team executes long-term plans and goals in a more disciplined fashion.

Keeping the IT systems separated but balanced can be a deliberate and strategic decision. Businesses that have outsourced application development might also want to keep their core IT infrastructure stable in order to keep control of software deliveries from their external partners, who work following agile principles.

Despite the neat separation implied by Bimodal IT, the different teams will need to cooperate. 7KH\$JLOH,7WHDPLVVWLOOGHSHQGHQWRQEDFNRIÀFHDSSOLFDWLRQVSURYLGHGE\WKHFRUH,7WHDP Both teams have to respect the different ways of working and agree on mutual processes. However, to avoid getting the teams too intertwined, it's good to create a layered or modularized base system architecture to from the beginning that provides and supports a high degree of change and agility above it.

Keeping two separate IT teams can prove to be a challenge. In order to create a bridge and to be DEOHWRSULRULWL]HEHWZHHQFRQÁLFWLQJLQWHUHVWVLW·VUHFRPPHQGHGWRKDYHD&,2PDQDJLQJWKHP

.

## When scaling Agile, avoid these common pitfalls:

**Senior managers often believe they fully understand and embrace agile principles, yet they demonstrate the opposite when making decisions.**6LWXDWLRQVOLNHWKLVFDQEHGLIÀFXOWWRUHFognize and mend whilst the managers in matter have attended training sessions and use the right agile buzzwords. It's not that they're faking it; they honestly believe they're doing the right things. So what can we do? Experience has shown that having more workshops, training, and discussions are not the most effective approach. A better way to tackle this situation is to let the management team visit another company for in-depth demonstrations and sharing sessions, and to introduce them to agile champions and leaders that can demonstrate what agile leadership really is about.

**Low maturity in a company's continuous integration and test procedures causes long quality feedback cycles.** To have successfully implemented procedures include at least daily integration and build, and some level of automatic testing. If the environment and processes don't allow for this, then further steps in the agile transformation journey have to focus on this. ,W·V VRPHWLPHVGLIÀFXOWWRLGHQWLI\ZKR VKRXOGGULYHWKLVFKDQJH7KHUHDUHPDQ\ VWDNHKROGHUV including production, legacy system owners, and quality assurance, and this makes running change DFWLYLWLHVGLIÀFXOW

**Administrative matters such as organizational structures, governance, forums and roles get more attention than the focus on achieving agility.** If development teams aren't agile, then we're scaling something that doesn't work. This causes unnecessary overhead in terms of coordination between teams and micro management of the whole program. So, make sure that GHYHORSPHQWWHDPVZRUNZHOOWKDWWKH\KDYHSURGXFWRZQHUVXVHDEDFNORJDQGKDYHDFOHDUGHÀnition-of-done. Ensure they are self-organizing and have the authority and skills to pull, plan and deliver their work and to get frequent feedback.

**Distributed development and dealing with multiple vendors are challenging.** Fundamental aspects of agile methods include a team's ability to self-organize, transparent collaboration, and quick feedback cycles. Geographical distance and cultural differences combined with multiple vendors and diverse business and contract models require a lot of the development organization. It's necessary to share visions, high-level goals and agreed-on deliveries between the different organizations, to maintain total visibility. Organizational boundaries have to be removed to get fully cross-functional teams. If you really need to engage multiple vendors, you also need a well-crafted outsourcing strategy that works with multiple suppliers.

#### **Stick to old ways for governing projects with demanding progress reporting hampers agility.**

With traditional governance – involving steering groups and traditional portfolio management – projects are burdened with detailed estimates in terms of investments and return, milestones and decision gates, and expected dates for deliveries. All results are basically a product of a project with all people and budget allocated in advance. Any deviation is managed by renegotiating project scope and budget, resulting in people get-WLQJVKXIÁHGEHWZHHQSURMHFWV:KHQZRUNLQJWUXO\DJLOHWKHUHDUH no projects with allocated people. Instead, there are a number of backlogs and a total development capacity. The developers organize themselves in teams that pull prioritized work out of these backlogs. All planning and governance is based on a quarterly, monthly, and weekly cadence. There are still people responsible for the business. They decide what and when to release. From a management point of view, this regime requires a lot of trust. It's important that there is full transparency to how much the teams can deliver per delivery. This enables product owners to make forecasts and reprioritize the next delivery.


## Get inspired

This scenario has been based on case studies of different companies that have made this journey, to scale with Agile. Learn from their experiences, what they gained and what they had to overcome.

#### Pruning a bush

At this company, any development of new functionality literally drowned in the work to VXSSRUWFXVWRPHUVDQGÀ[EXJV5HDGDERXWKRZWKH\LPSOHPHQWHG6&580DQG.DQEDQ without jeopardizing the relations with their customers and quality in their old products.

#### Ensuring prima deliveries

Critical bugs passed unnoticed for weeks or even months. Corrected bugs took days or weeks to deliver, since the procedure is manual and requires the system to be shut down This was the situation when a team at Prima decided to implement Continuous Delivery.

The company had long release cycles due to their lack of capacity but mostly because their FXVWRPHUVGRQRWZDQWFKDQJHVWRRRIWHQ0DQ\SURGXFWVLQWKHÀHOGQHYHUHYHQJRWXSGDWHG products that the company's technicians needed to be able to maintain and service. A few of the larger customers desired to have the products branded as theirs. The consequence was a complex branching strategy (a way to keep track of the software for each customer). Every bug QHHGHGWREHÀ[HGDQGWHVWHGLQDOORI WKRVHEUDQFKHV7KLVPDGHWKHUHOHDVHVYHU\GLIÀFXOW7KH many branches made it impossible to keep their release deadlines.

Any development of new functionality literally drowned in the work to support customers and WRÀ[EXJV7KHGHYHORSPHQWGHSDUWPHQWZDV drenched in work and very little new software was produced. However, a new product was in the roadmap. The organization knew they needed to make this a priority without jeopardizing the relations with their customers and quality in their old products.

The many and conflicting patches made integration and verification very difficult. The team had to move all patches from the release branch to the main branch. Sometimes there were several release branches to merge into the main branch. It was a mess.

The maintenance team added the patches directly on the customer's production branch at any time. So when a new release was created, all patches from the different customer branches had WREHDGGHGWRWKLVUHOHDVH7KHPDQ\DQGRIWHQFRQÁLFWLQJSDWFKHVPDGHLQWHJUDWLRQDQGYHUL-ÀFDWLRQYHU\GLIÀFXOW+DYLQJUHOHDVHGWKHWHDPWKHQKDGWRPRYHDOOSDWFKHVIURPWKHUHOHDVH branch to the main branch. Sometimes there were even several release branches to merge into the main branch. It was a mess.

The Agile transformation started by training the development teams, product owners and managers in Agile, Scrum and Kanban methodologies**\***. After the training was completed, new ways of working were introduced in a big bang. The department was divided into three development teams. The team that got responsibility for maintenance started to work according to Kanban. The team that got to work with customer projects and the team that got to work with new prod-

> www.scrumalliance.org \* kanbanblog.com/explained

ucts started to work according to Scrum. The people in the test team were all distributed in the DJLOHWHDPV7KH\ZHUHDVVLJQHGWRZULWHXVHUVWRULHVGHÀQHDFFHSWDQFHFULWHULDDQGDOVRWRWUDLQ the developers in how to test. The testers could now focus on more complex test cases and the overall quality.

([WHUQDOFRDFKHVIDFLOLWDWHGWKHÀUVWVSULQW7KHUHVSRQVLELOLW\ZDVWKHQKDQGHGRYHUWRWKH team's Scrum masters and Kanban leaders. The two development teams adapted quickly and started to produce and solve challenges as they arose. The external coaches were still available, to support the teams, the scrum master and the managers in their new roles. They also got help with their group development, to help them in seeing how to improve. The branching strategy ZDVFKDQJHGDIWHUDWKRURXJKDQDO\VLV1RZDOOEXJÀ[HVDQGQHZIXQFWLRQDOLW\KDGWREHWHVWHG and merged into the main branch after every sprint.

\$VWKHPDLQWHQDQFHWHDPVWDUWHGWRZRUNZLWKVPDOOHUEDWFKHVRIEXJÀ[HVWKH\FRXOGDVZHOO take the step and merge corrections both into the service pack release branch and the main EUDQFK,QWHJUDWLRQDQGYHULÀFDWLRQRI HYHU\EDWFKZHQWVRPXFKIDVWHU7KH\FRXOGLQWKLVZD\ guarantee the quality on both branches.

,WWXUQHGRXWWREHYHU\LPSRUWDQWWRQRWH[FHHGEXJÀ[HVLQDEDWFK7ZLFHWKHWULHGWR LQFOXGHEXJÀ[HV%XWDIWHUKDYLQJGLVFXVVHGWKHHIIHFWVLQUHWURVSHFWLYHWKH\FRQFOXGHGWKH\ RXJKWWRVWLFNWR:LWKEXJÀ[HVLWVLPSO\WRRNWRRORQJWLPHWRGRWKHLQWHJUDWLRQDQG YHULÀFDWLRQ%\VWLFNLQJWRWKHUHOHDVHVFRXOGEHÀQLVKHGRQGHDGOLQHDQGZLWKRXWDQ\RYHUtime. They hadn't been able to do this for a very long time, a huge step forward according both to management and the employees.

To get the software departments up and running with Scrum and Kanban required two weeks of initial training.

## **Ensuring prima deliveries** CASE STUDY / Deliver 24/7

140 138

Many organizations are suffering from sub-optimal development and deployment processes. Common bottlenecks are: outdated tools, lack of systematic and pro-active error handling procedures, and deployments that only can be made at night time in order to limit downtime. The consequences are low quality and delayed deliveries. The feedback loop from customers to developers tends to be too long. Critical defects can pass unnoticed for weeks or even months. :LWKPDQXDOGHSOR\PHQWSURFHGXUHVWKDWUHTXLUHDV\VWHPWRJRRIÁLQHGHIHFWÀ[HVPLJKWWDNH days or weeks to deploy.

This was also the situation when the Swedish company *Projekstyrning Prima* (Prima) decided to implement Continuous Delivery of its route planning systems. To that end, Prima developers introduced new systems for source control management, build automation, automated deliveries, and a new way to log information – one module and one developer at a time. These steps made a great difference WRWKHLUSURGXFWLYLW\WKHLUOHDGWLPHVWRFRUUHFWEXJVDQGWKHLUFRQÀGHQFHLQWKHLU SURGXFWV,WZDVQRORQJHUQHFHVVDU\WRWDNHV\VWHPVRIÁLQHIRUDQXSGDWHRUWR work long nights or weekends. With this set of tactical changes, new product versions could be deployed in the middle of the day, without any downtime. The UHVXOWLQJVKRUWHUF\FOHVDQGIDVWHUGHOLYHULHVRI ERWKIHDWXUHVDQGGHIHFWÀ[HVOHG to increased customer satisfaction and fewer calls to Prima's support lines. The shorter cycles also made it easier to plan the work ahead on a realistic time scale, and measure effects such as product quality of their new approach.

New way to log information – one module and one developer at a time

New systems for source control management, build automation and automated deliveries

The key driver for Prima was to increase the release cadence without jeopardizing the quality and stability of the product. To make this possible, the development pipeline had to be fully auto-PDWHGZKLFKLWVHOI UHTXLUHGVRPHVLJQLÀFDQWXSGDWHVRI WKHLUH[LVWLQJWRROFKDLQ

Prima was using the Microsoft Azure cloud platform, but this wasn't a key problem. The challenges they ran into could have arisen with any cloud technology stack. While cloud technology certainly facilitates a transformation to continuous delivery, this wasn't a key requirement.

The changes that the Prima team made took just over three weeks – less than 16 days to be precise. Some of the major improvements were made by rethinking and simplifying the product release procedures. Another cornerstone for making improvements was to introduce monitoring systems: detecting when things go wrong is essential to continuously improving processes and removing bottlenecks. This continuous improvement is key in true enterprise agility and can also be traced back to the Lean Thinking philosophy. Continuous improvement is not the destination—it is the journey itself.

New source code management system

Cloud platform

Microsoft Azure

Lean Thinking is derived from the Toyota production System, which itself contains many concepts using Japanese words. One simple tactic is described by "Genchi Genbutsu", which refers WRWKHVLPSOHDFWRI JRLQJWRWKHSURGXFWLRQÁRRUWRVHH´ZKDW·VJRLQJRQµ%\VLPSO\OHWWLQJD coach walk through the steps with every member of the team helps to overcome many problems. Soon it became clear that the chance to succeed increases if everybody knows the whole team, and the product, before embarking on this journey. Of course, using support from modern tool chains is a necessity. These tools don't need to be very expensive—many of the tool chains are available free of charge as open source products. While some tool migrations might take some effort, such as migrating to a modern source code management system, such investments will pay off in the end. This is one of the many trade-offs that teams will have to make in a process improvement initiative.

143 141

The scaling Agile model is for companies that want to star<sup>t</sup>working with Agile on a larger scale. The complete model describes scaling in three domains: size, offerings and value stream.

 This chapter focuses solely on the size domain.

145

The model is for companies that aim to extend the number of people in the value stream so that more teams work together towards a joint delivery. The typical starting point is that a development department has been using Lean and Agile successfully for a few years, and now they wish to spread the ways of working through the rest of the company.

:KHQVFDOLQJDEXVLQHVVLQWHUPVRI HIÀFLHQF\DOOWKDWPDWWHUVLVKRZWREXLOGWKHSURGXFWV faster, more predictable and in bigger volumes. Innovation is not a matter at this point. This is a business need that mostly appears in very large companies that deliver complex products or services to the market. They search for ways to be more productive together in an organization that suffers from too many dependencies between products, services and departments. This

FRPSOH[LW\PDNHVWKHRIIHULQJVHQVLWLYHWRFKDQJHVDQGWKHRUJDQL]DWLRQOLNHO\VSHQGVVLJQLÀFDQW resources on maintenance. What complicates everything is that the scaling would need to be made without serious interrupts in the product development. This is where scaling Agile comes in, an approach cut out for the change.

Agile development, for example Scrum and Kanban**\***, has rapidly proven to be the preferred methodologies among software teams and their developers. Even if a company formally hasn't made the switch to use Agile methods, it's not unlikely that some of their teams already have started to work this way. Teams working in an Agile fashion strive for clear goals and boundaries, open communication with full visibility of decisions and priorities.

Letting go of details and focusing on Lean and Agile principles will turn out to be challenging for most managers in a traditional organization, even if it's been successfully proven empirically. They have to be courageous and trust in the method and in the staff they manage. In fact, Agile provides discipline, transparency and working code frequently so trust will come by itself. It's important to grasp the idea that scaling Agile has no end; this is the way the organization is run.

Organizations that have been scaled in this way shows that they are able to deliver utterly com-SOH[SURGXFWVDQGVHUYLFHVZLWKUHPDUNDEOHHIÀFLHQF\7KHUHDUHRI FRXUVHSLWIDOOVDKHDGZKHQ IRFXVLQJRQHIÀFLHQF\RYHUDWRRORQJSHULRGRI WLPH:KLOHEHLQJUHDFWLYHLVFRQVLGHUHGJRRGLQ Agile, it's important to consider all customer requests carefully. The product owner has to make the right priorities. It's important to not forget to start innovate again.

There are several frameworks for scaling Agile and there is no right or wrong choice. A decision of what combination of frameworks to use can be made once there is an agreement of what is relevant to the organization. If you already use Scrum in the company, you might want to consider LeSS (Large-Scale Scrum). LeSS is sprung out of complex R&D development and emphasizes on contin-

uous learning, inspection and adaption of both product and processes from a systemic point of view. If portfolio and program level management is central to your company, you might want to get a closer look at SAFe (Scaled Agile Framework\*). SAFe put emphasis on governance, program and portfolio management and in particular suitable for organizations from hundreds to thousands of developers.

All frameworks have their differences but they all share the Agile principles. This means also that the change will require new roles and ways-of-working, even in an organization that uses Agile development methods. It's a good idea to form a cross-functional change team. To change the mindset of leadership and the governance will be one of the biggest challenges in this transformation. One of the most important principles of Agile software development is to have

self-managed co-located cross-functional teams working. The teams should understand the requirements fully and have all necessary competence to take all decisions for the functionality that they are responsible for. Read more about change in **Your journey**.

Another important aspect is to have close cooperation between the product management and the development team. Ideally product management competence must be in the self-managed teams, so that the communication is fast and direct. But there are some Agile frameworks that promote to have the product management in a central team. Whichever way this is organized FRPPXQLFDWLRQQHHGVWREHGDLO\7HDPVQHHGWRUHJXODUO\UHÁHFWRQKRZWREHFRPHPRUHHIÀcient. This should ideally be done regularly.

Follow up on progress in software-based projects is usually a big challenge. In an Agile project WKHSURJUHVVLVPHDVXUHGE\FRGHWKDWLVDFWXDOO\ZRUNLQJDFFRUGLQJWRWKHGHÀQLWLRQRI 'RQH Since functionality is split up in smaller pieces (chunks), this is a proven way to measure progress. This also drives customer satisfaction, due to that customers can give their feedback in early phases of the development cycle instead of at the end of a project. Customers usually want VSHFLÀFIHDWXUHVZKLOHHQJLQHHUVOLNHFRPSOLFDWHGLPSOHPHQWDWLRQVWKDWFRYHUHYHU\WKLQJ7KLVLV why emphasis is put on choosing the simplest possible solution. It makes customers happy and engaged already in the early phases of the software development lifecycle.


## Get inspired

This scenario has been based on case studies of different companies that have made this journey, to scale with Agile. Learn from their experiences, what they gained and what they had to overcome.

#### Global R&D goes agile with SAFe

7KLVVWXG\IURP(ULFVVRQEULQJVXSWKHGLIÀFXOWLHVLQLPSOHPHQWLQJ\*R\$JLOHZLWK6\$)HLQD global organization.

#### Multi-site development

If you're into services, you might want to read about how the large mobile operator gained excellent predictability by visualization.

www.scaledagileframework.com \*

The global high tech company had struggled for quite some time to deliver as promised. This had created a strained relationship between the company and their customers, which seldom believed in the promised dates and the quality of the deliveries. When the customers got back to the company they had to wait far too long to get corrections. The market competition was at the time getting tougher and tougher for the company. Many competitors aspired to be the rising VWDU7KHFRPSDQ\KDGWRUHDOL]HWKDWWKH\KDYHWREHPXFKPRUHHIÀFLHQW7KH\KDGWRPDNHWKH most out of their employees to speed up development and to solve customer feedback cases.

These drivers initiated their Agile transformation:

7KHÀUVWLGHDVRI KRZWRVWUXFWXUHWKHRUJDQL]DWLRQZHUHIRUPXODWHGLQ7KHIRFXVZDVRQ VSHHGDQGKRZWRÀJKWFRPSHWLWLRQIURPRWKHUSODWIRUPSURYLGHUV7KHWUDQVIRUPDWLRQMRXUQH\ VWDUWHGLQPLGE\WKHFUHDWLRQRI DQRUJDQL]DWLRQWKDWZRXOGIXOÀOOWKHGHPDQGVIURPWKH current mobile platform market.

The organization was set up as an R&D organization parted in four requirement areas (RA) and RQHLQWHJUDWLRQ YHULÀFDWLRQRUJDQL]DWLRQ(DFK5\$ZDVUHVSRQVLEOHIRUHLWKHUDWHFKQRORJ\ area (like core SW) or a function area (like test). These RAs were located to 4 different sites over the world; in fact, the same RA could even be distributed over several different sites. About 800 people in Sweden and about 1500 persons globally were affected by the transformation. The change was led by a core team working in an Agile way, using whiteboards and visualization.

The R&D organization improved well, both the integration time and the customer response time decreased. A major reason this went so well was that the introduction of Continuous Integration and Continuous Delivery. Read about this in the chapter **Deliver 24/7**. Another reason was the coaches, who worked with the teams to help improve transparency and collaboration. A stable change velocity helped the product management to make releases predictable. Realizing that more and more Agile tools actually worked, they completely changed their mindset. A year after the start of the transformation, the company was able to manage a full program increment, an activity that last over a quarter of a year. At this point in time, everybody in the organization could go to the visualization room and have a look at the different RA plans, goals and KPIs. Everything was updated on a regular basis.

The biggest challenge in the transformation was to change the mindset in the organization. Slowly, small success stories spread in the company, making people to start trust one another. A FXOWXUDOFKDQJHOLNHWKLVWDNHVDORQJWLPHDQGQHHGVWREHJLYHQVXIÀFLHQWIRFXV

CASE STUDY / Pump up the volume

## **Multi-site development**

The management of a large mobile operator had realized that one of their biggest projects was not progressing at all. The project had been planned as always, in accordance with waterfall principles. \$OOVSHFLÀFDWLRQVKDGEHHQFUHDWHGDQG\HWQRRQHNQHZKRZWRVWDUW:LWKORWVRI PRQH\DQG prestige already invested in the project, it simply had to succeed.

The project aimed to merge a multitude of different systems, of different age and status, into one big system. Part of the development was made in-house, but part were also made by many vendors spread over the world.

Productivity ,QWKHLUFXUUHQWV\VWHPLWZDVGLIÀFXOWWRÀQGNQRZOHGJHDERXWWKHLUFXVWRPHUV7KHLQIRUPDWLRQ was spread out over different systems and customer service needed to access all these systems to support their customers. But, the work took a long time and it was hard to train them. The system ZDVSUDFWLFDOO\LPSRVVLEOHWRZRUNZLWK,WZDVSDUWLFXODUO\GLIÀFXOWWRFUHDWHEXQGOHGSURGXFWV across different channels. The tools needed existed, but resided in systems that were not connected. They desired to create a cohesive experience across all channels. It should look and feel the same on all platforms.

7KH\ÀQDOO\XQGHUVWRRGWKDWVXFKDPDVVLYHDQGFRPSOH[SURMHFWFRXOGQRWEHWKRURXJKO\SODQQHG from the start to the end. A clear goal had to be set and the solution had to develop over time, with tight learning and feedback cycles. That's when they decided to start working with an Agile methodology.

First they implemented Scrum as a project methodology. They divided the large in-house team into two smaller teams, to keep the team members focused. A single, prioritized backlog was created and the teams started to develop based on it. This change alone turned out to be one of the most important ones they ever made in the project. During the following six months, an extensive UHFUXLWLQJWRRNSODFH,QWKHHQGÀYHWHDPVZRUNHGVLGHE\VLGHRQWKHVDPHSURMHFW

But one challenge remained. They didn't manage to solve the long lead times that were required for each new function they added. The many dependencies between teams and vendors made it YHU\GLIÀFXOWDQGPDQ\IXQFWLRQVKDGWREHLWHUDWHGDIHZWLPHVEHIRUHWKH\ZRUNHG9HORFLW\E\ which each team was measured, turned out to be useless as a mean to estimate the releases. Depen-GHQFLHVZHUHKDQGOHGGXULQJWKHUHÀQHPHQWRI DWDVNE\SUHRUGHUIURPWKHWHDPWKDWGHSHQGHG RQFHUWDLQIXQFWLRQDOLW\:KHQDWDVNZDVGHYHORSHGEDVHGRQWKHVSHFLÀFDWLRQVLWRIWHQKDGWREH UHGRQH7KHWHDPWKDWRUGHUHGWKHIXQFWLRQDOLW\LQWKHÀUVWSODFHZRXOGWKHQRIWHQÀQGVRPHWKLQJ that needed to be changed, and place a new pre-order.

7RKDYHDQ\FKDQFHWRVXFFHHGWKH\QHHGHGWRUHGXFHWKHOHDGWLPHDQGWKHVLJQLÀFDQWDPRXQWRI ongoing work. The change team concluded in that Scrum had to be replaced by Kanban, in each team and on a project level. Work-in-progress limits is the key principle in Kanban. Additionally,

a limit was set of how much ongoing work was allowed at the same time. On project level, a Kanban board was introduced. It gave an overview of the features each team was working on. A clear ´GHÀQLWLRQRI GRQHµZDVDOVRGHÀQHGEHWZHHQHDFKWHDP7KHSURMHFWPDQDJHPHQWFRXOGQRZ use this board and start estimate throughput and lead times on an overall level. They had real data to analyze in order to see if the project was going to manage the project deadline. They could now

A lot of time is lost on coordination because teams are not able to take decisions on their own

160 158

re-prioritize based on this information. Each team and vendor got such a Kanban board, enabling them to prioritize tasks and solve their bottlenecks. They also introduced collaborative analysis and design, in which key people from each team met and talk through each task, what the task means to them.

A key get-away from the project was the importance of visualizing work in progress on both project and team level, to make sure problems are detected fast. They solved it by start using JIRA**\*** in the cloud, by this enabling smooth access by both external and in-house teams.

To split the original organization into two teams and start running Scrum took a couple of weeks. ,WWKHQWRRNDOPRVWVL[PRQWKVWRH[SDQGWRÀYHWHDPVDQGDQRWKHUVL[PRQWKVWREHFRPHDZDUH that the set up was not working. The resulting move from Scrum to Kanban, to get all teams and vendors on board and get everyone involved in the collaborative meetings, took another six months.

\$NH\PRWLYDWLRQIRUWKHFKDQJHZDVWRPDNHWKHLUYHU\ODUJHSURMHFWÀQLVKEHIRUHGHDGOLQH7KH\ desired to be able to predict what part of the scope could be completed by that time. By being able to do this, they could then re-prioritize early and solve problems as they appeared.

Did they deliver in time? Yes, they did.

#### Quality Productivity Project predictability Long lead times Quality not sufficient Problem with visibility in project follow up A lot of time is lost on coordination because teams are not able to take decisions on their own Plans are not followed up Customers frequently dissatisfied with the outcome Increased quality Close, daily cooperation between business people and developers where plans are adapted to current situation Implement Agile work-flow Customer satisfaction by early and continuous delivery of software Regularly, the team reflects on how to become more effective and adjust accordingly Co-located self-managed teams with prioritized backlogs of requirements Working software is the principal measure of progress Implementing the simple solution New architecture that sup- Increased productivity Software organization deliveries are predictable Very little cooperation between development and product management Requirements are not always understood by the developers

ports agile way of working

## There is no room for bugs and maintenance updates when life is at stake

Some businesses imply severe demands on design and manufacturing.

163

Take a car maker, or a manufacturer of dialysis machines. A software bug in their products could have serious consequences on public or personal safety. Rigorous safety and quality norms have to be met by these products and services to reduce risks to acceptable levels.

Regulated domains, such as automotive and healthcare, are compliance oriented. Products and VHUYLFHVQHHGWRDGKHUHWRGRPDLQVVSHFLÀFVWDQGDUGVDQGVRGRHVWKHSURFHVVRI GHYHORSLQJ manufacturing and deploying those products and services. Consider the automotive domain, for example. A car contains parts and components from thousands of suppliers. In Europe, the Original Equipment Manufacturer (OEM) takes full responsibility for the product and has to be certain that all the parts from its suppliers are compatible in performance, durability, and many other qualities attributes. All parts need to be engineered and produced according to stringent quality standards. Quality standards are not enough, though. Additional requirements such as safety and security have also been deployed as standards.

0DQ\UHJXODWRU\UHTXLUHPHQWVVHHPWRFRQÁLFWZLWK\$JLOHVRIWZDUHGHYHORSPHQWSULQFLSOHV)RU example, the Agile Manifesto values working software over documentation—yet, it is documentation (e.g. for process traceability) that is so important in regulated domains. Therefore, it's still a challenge to apply Agile development methods within these domains.

### Drivers

Agile methods have seen widespread adoption in the software industry with some surveys suggestion adoption rates of up to 80%, and for good reasons. The iterative, time-boxed approach with regular feedback cycles helps to improve software quality and customer satisfaction, and to improve developer productivity. Many of the drawbacks of traditional waterfall-based approaches can be overcome with Agile methods. However, Agile methods were initially seen as inappropriate for use in regulated domains such as the automotive industry and medical devices.

In the last few years, driven by market demands and companies' desire to improve their development processes, this assumption has been challenged, and companies in various regulated GRPDLQVKDYHH[SORUHGKRZWRDGRSW²DQGDGDSW²\$JLOHPHWKRGVIRUWKHLUVSHFLÀFEXVLQHVVGRmain. This is also driven by trends such as digitalization in society and Internet of Things. While safety requirements are still of primary concern, even companies in these regulated domains need to consider the increasing demand for new and innovative software.

So, the drivers that have led many companies to adopt Agile development methods also play an important role in companies that are subject to regulations and standards. 7KH\KRSHWRDFKLHYHEHQHÀWVVXFKDVTXDOLW\LPSURYHPHQWVFRVWUHGXFWLRQDQG shorter time-to-market. But they also have to get better in communicating with the consumer. The digitalization trend that sweeps through our industry, and society at large, is changing customers' expectations. Customers now expect to interact with devices through web-based interfaces, and seamless interconnectivity between different devices.

Companies in regulated domains have traditionally been using waterfall-based development approaches, including the "V-model," an extension of the waterfall model, but many are now moving towards agile methods. However, while DGRSWLRQRI PHWKRGVDOZD\VUHTXLUHVWDLORULQJWRDVSHFLÀF development context, regulated domains require a number RI VSHFLÀFFRQVLGHUDWLRQV

A number of general factors affect how a company should tailor agile methods. Some of those factors are:


In regulatory businesses, a product has to be proven to be safe. To this end, a company can create <sup>a</sup>*Safety Case*, which consist of structured arguments supported by evidence that the sys-WHPLVDFFHSWDEO\VDIHIRUDVSHFLÀFDSSOLFDWLRQLQDVSHFLÀFRSHUDWLQJHQYLURQPHQW

> 7KHUHDUHHVVHQWLDOO\ÀYHSULQFLSOHVWKDWVXPPDUL]HVVDIHW\ UHTXLUHPHQWV IRU software:

7KH\VKDOOEHVDWLVÀHG

We have

evidence

the right

requirements

We meet the

requirements

We use the

correct

processes

	- They shall address the software contribution to system hazards
		- +D]DUGRXVEHKDYLRURI WKHVRIWZDUHVKDOOEHLGHQWLÀHGDQGPLWLJDWHG
		- 7KHFRQÀGHQFHVKDOOEHPDQDJHGLQUHODWLRQWRWKHV\VWHPULVN

In order to provide evidence to the safety case, a few areas need WREHIXOÀOOHGDOWKRXJKWKH\DUHQRWVWULFWDJLOHZD\VRI ZRUNLQJ


We have a good safety culture All these areas have to be adhered to satisfy the safety standards. ,W·VQRWUHJXODWHGKRZWKHVHDUHVDWLVÀHGEXWWUDGLWLRQDOO\WKLVKDV been accomplished by using a waterfall development method, with a KHDY\YHULÀFDWLRQDQGYDOLGDWLRQSKDVHDWWKHHQG\$VKRUWWHUPVROXtion of how to move away from waterfall development principles is to UHSODFHWKHKHDY\HQGRI WKHSURMHFWZLWKYHULÀFDWLRQDQGYDOLGDWLRQRI UH-OHDVDEOHSURMHFWLQFUHPHQWVIROORZHGE\DÀQDOEXWVPRRWKYDOLGDWLRQDWWKHHQG of the project. A long-term strategy requires the industry to change the standards in a more Agile direction.

There is a short-term strategy for any company in regulated environments that wants to work agile: Apply as many Agile ideas in the development organization as possible by still following WKHVWDQGDUGVWKDWQHHGVWREHIXOÀOOHG<RXZRXOGQ·WJHW\$JLOHE\WKHERRNEXWDV\$JLOHDVSRVVL-EOH%\PDNLQJWKHIROORZLQJDGRSWLRQVPRVWFRPSDQLHVFDQSURÀWIURPWKHEHQHÀWVWKDW\$JLOH software development has to offer.

7KHKDUGZDUHDUFKLWHFWXUHLVWUDGLWLRQDOO\UHÁHFWHGLQWKHVRIWZDUHDUFKLWHFWXUH7KLVKDVVRPH advantages, but also some disadvantages. It is worthwhile to split the architecture in two or more parts, where some are connected to regulatory aspects and others are not. This makes it possible to also split the organization in the same way, enabling the parts that are not affected by regulatory requirements to work in a more Agile way.

Introduce autonomous teams with full functional responsibility and by this reduce handovers and dependencies. Making decisions at the right place encourages furthermore commitment, engagement and minimizes changes and task switching.

The development work can be done in an iterative way. Create a so-called minimum viable product in weekly or biweekly steps. Always having working code increases the overall quality of the software.


## Get inspired

This scenario has been based on case studies of different companies that have made this journey, to scale with Agile. Learn from their experiences, what they gained and what they had to overcome.

#### **Scaling Agile in Automotive**

Kugler-Maag are a key player who aim to bring innovations to the automotive sector, including the use of agile software development methods and open source software.

#### **Scaling Agile in Life Sciences**

Agile methods were originally considered unsuitable for regulated domains, but QUMAS found a way to scale the Scrum approach to be compliant with the standards and regulations in their domain.

## One more thing

Scaling a software organization in the regulated domain seldom means to only implement Agile ways of working. Many organizations have to redesign their software architecture. Continuous delivery usually gets a high rank in the wish list. The organizations also tend to see clear competitive advantages in adapting to service-oriented business models and to work in a network of co-creators that uses open source software. All these areas have been covered by other scenarios in this book.

174 172

The automotive industry is going through a huge transformation. The entire industry has been disrupted by a connectivity trend. This case study is based on an industry survey conducted by Kugler Maag Cie,**\*** a leading consulting company with many of the well-known car manufacturers as its customers. Over 40 expert interviews with decision-makers in the automotive, IT and tele-FRPPXQLFDWLRQVLQGXVWULHVZHUHFRPELQHGZLWKDQRQOLQHVXUYH\WRÀQGWKHPDLQLQÁXHQFHVWKDW affects software development. The conclusion represents the transformation that the automotive industry is in the middle of.

This study involved interviews with over 40 experts and decision-makers in the automotive, IT and telecommunications industries. A large-scale online survey was subsequently conducted to identify the key trends with respect to the role of software and its development in the automotive indus-WU\7KHNH\ÀQGLQJLVWKDWVLPLODUWRPDQ\RWKHUGRPDLQVWKHDXWRPRWLYHLQGXVWU\LVFXUUHQWO\ experiencing a major transformation as the role of software is becoming increasingly important.

Customers expect their cars to be web-enabled, with many advanced features that are now custom for smartphones. Cars get increasingly more features, and similar to trends found in the smartphone industry, the car becomes a platform to which customers can seamlessly connect their peripheral devices. As a result, this increasing demand for new features and innovation delivered more quickly requires that the automotive industry responds more quickly. This is where the industry hopes the promises of agile methods can be realized. Implementing agile practices such as continuous delivery is not without its challenges, but it doesn't have to be an impossible mission.

The architecture is replaced by a layered and service-oriented architecture, containing a physical and a connected layer. This requires R&D to replace proprietary component-oriented product architectures with Internet enabling service architectures. The latter inevitable changes the R&D organizations, mostly because the culture in the organizations performing the R&D tasks for these two layers will develop differently. They have to work in a Bimodal way by focusing on speed of innovation and inter-disciplinary cooperation at the connected layer and focusing on quality and safety at the physical layer.

Also in automotive, development communities are expected to emerge dynamically around services.

The car manufacturer needs to work with open standards to quickly adjust to different organizational cultures of changing partners. In an agile organization, independent but networked units FDQTXLFNO\DQGÁH[LEO\EHUHFRQÀJXUHGDVWKHZRUOGFKDQJHV

This is perhaps the most challenging part of the transformation, this that services become more LPSRUWDQWWKDQSURGXFWVDQGRQO\DVPDOOVKDUHRI WKHSURÀWLVFUHDWHGWKURXJKVDOHVRI SK\VLFDO products. The cultural challenges far outweigh the technological challenges.

The Internet of Things phenomenon is a critical enabler to gain more sales through service based business models. The executive management must acquire the necessary core competence to harness the emergent power of this new technology.

Once a car moves into its production phase, software development must carry on and add new functionality. Cars have to support updates and add-on apps that are developed after delivery. Naturally, the start of production-focused development has to be replaced by continuous development with short release cycles. By the architectural changes already mentioned, in combination with standardized hardware with performance reserves, the functionality of the car can be expand-HGVLJQLÀFDQWO\

To enable fast return on investment, the organization needs to optimize the time to transit soft-ZDUHFKDQJHVWRWKHÀHOG,WKDVWROHYHUDJHIURPVWDQGDUGVWKURXJKDSODWIRUPWRJHWWUXO\VXFFHVVful with continuous development, to enable additional revenue in the longer term.

Open source software in vehicles is already a reality. Open source will also become widespread in functionally critical software. This will in turn affect the organizational structure of companies as well as the way of working. The transformation has not really an end state.

176 174


CASE STUDY / Agile and disciplined

178 176

## **Scaling Agile in Life sciences**

to the needs of regulated environments

Agile methods have long been thought only to suit small projects with co-located teams that don't operate in regulated domains such as the automotive and medical sectors. This case study describes how QUMAS, a leading supplier of regulatory compliance management software to the life sciences sector has tailored the standard Scrum framework to regulated environments.

QUMAS had employed a classic Waterfall approach ever since the company was founded. The approach resulted however in a long time-to-market and a large release overhead, all-in-all quite serious weaknesses on a rapidly changing market such as the one QUMAS operates in. To combat this, the company spent about two years to adopt and augment the Scrum methodology.

The Agile Manifesto offers four value propositions:

**Individuals and interactions** over **Processes and tools Working software** over **Comprehensive documentation Customer collaboration** over **Contract negotiation Responding to change** over **Following a plan**

While agile advocates accept that the blue statements on the right are important, they value the red statements on the left more. However, in regulated environments, the blue statements on the right loom very large and are perceived to be key. If it isn't documented, it isn't done is a frequent refrain in the regulated domain. Agile methods may for that reason appear to be inap-SURSULDWHIRUUHJXODWHGGRPDLQV7KH\DUHQ·WRI FRXUVHEXWWKH\QHHGWREHWZHDNHGWRÀWWKH regulatory requirements.

7KHVWDQGDUG6FUXPIUDPHZRUNGHÀQHVUROHVFHUHPRQLHVDQGDUWLIDFWV7KHSURGXFWRZQHU the team, and the scrum master are for instance roles. The ceremonies include activities such as the daily stand-up, the sprint planning meeting, the sprint review and the retrospective meeting. Artifacts include the product backlog, the sprint backlog and at the end of every sprint, a "shippable" product. QUMAS's development process is regularly audited. In order to comply with the various regulations they are subject to, QUMAS has extended the standard Scrum framework with a number of additional roles, ceremonies and artifacts, resulting in R-Scrum: Scrum for Regulated domains.

#### **New roles**

Quality Assurance User documentation

180 178

#### **New Ceremonies**

Dev Check QA Check Point Hardening sprint

#### **New Artifacts**

Marketing demo material Updated design documentation Non-conformance report

Quality Assurance is an important additional role in R-Scrum. Regulations require that QA is independent from the development team. The QA Check Point is a new ceremony that takes place after every sprint, when QA conduct an internal audit to ensure "continuous compliance". Rather than conducting an extensive, annual audit, audits now take place after every sprint. Any issues that emerge during the audit are reported in a non-conformance report, which is addressed in the next sprint.

The user documentation role is also new and assigned to at least one member of the development team. The team has also got a new ceremony, the Dev Check. After a task is completed, any code and documentation is peer reviewed by another developer. This is required by the regulations that QUMAS must adhere to. Another new ceremony, the hardening sprint, should be GRQHMXVWEHIRUHWKHÀQDOUHOHDVHWRHQVXUHWKDWWKHSURGXFWLVIXOO\FRPSOLDQWZLWKDOOQHFHVVDU\ regulations.

Traceability is a key concern in regulated domains. QUMAS have adopted the Atlassian toolset, which offers full end-to-end traceability. Jira is used for issue tracking and project management. Other tools in the toolset offer source code search, an enterprise wiki, agile planning and project management, continuous integration, and peer review. The toolset is a key ingredient to the Agile transformation and facilitates a very effective audit process.

## Lessons Learned

QUMAS have successfully tailored the standard Scrum framework to facilitate the additional constraints imposed by the regulations that their development process must consider. The key lessons learned of this case study are:


The sprint-based approach allows QUMAS to always be able to demonstrate the latest version to potential customers. The marketing demonstration material is always up to date. This has greatly improved QUMAS' sales opportunities. Based on product demonstrations, several customers have pre-ordered new products, even when they were still under development. This by itself is noteworthy, and is untypical of in regulated domains.

7KH´VFDOLQJµRI 480\$6·GHYHORSPHQWSURFHVVKDVDOVRKDGDVLJQLÀFDQWLPSDFWRQWKHRUJDnizational and the product domains. QUMAS' story is therefore representative of the "scaling software" phenomenon that this book focuses on.

.

<sup>183</sup> 181

SCENARIO / Offshoring/Outsourcing

Over the years, focus in outsourcing and offshoring has gradually shifted from low-cost to factors such as qualified personnel, ability to ramp resources and access to an international market. To solely focus on low-cost has turned out to be counter-productive.

185

Even if development cost reduction is the most common reason for choosing Outsourcing or Offshoring as a software development strategy, there are many other reasons why companies embark on such an endeavor. A bit of clarity over the terms will shed light on what these other EHQHÀWVPLJKWEH

**Outsourcing means that we contract a third party to develop what we used to develop ourselves. They can very well be located in the same town as we are.**

**Offshoring means that we relocate all or part of our development to another country. We are still doing the development; we're just doing it abroad.**

Putting the low-cost aspect aside, managing workload peaks is a good reason to choose outsourcing, as it is costly and risky to build up and maintain internal overcapacity. Further, to balance our investments and risks, it also makes sense to have our own developers working on the most important areas and letting a third party take care of less critical development. Another EHQHÀWWKDWRXWVRXUFLQJEULQJVLVDJLOLW\LQVFDOLQJGHYHORSPHQWFDSDELOLWLHVERWKLQFUHDVLQJDQG UHGXFLQJDQGWKHUHIRUHDELOLW\WRIDVWHUUHDFWWRPDUNHWDQGEXVLQHVVÁXFWXDWLRQV

The reasons for choosing offshoring are similar as those for outsourcing. Another good reason is the continuous character of an offshoring relationship, with permanent cost reductions and without the hassle of contract negotiations with vendors. Moreover, it enables organic knowledge transfer, growth and "follow-the-sun development."

Many companies choose near-offshoring where time zone differences are minimal and travel time is short between locations. Other companies decide to offshore to regions very far and with time-zone differences of six hours or more.

,W·VUHDOO\DPDWWHURI KRZIDUZHZDQWWRWDNHLW,W·VJHQHUDOO\PRUHGLIÀFXOWWKHORQJHUZHJHW and the more we detach. But it's not impossible. So, bear with us while we outline a strategy that can get you where you want.

## The unforeseen costs

Over the years, the trend in outsourcing has gradually shifted focus from reducing costs to factors VXFKDVDYDLODELOLW\RI TXDOLÀHGSHUVRQQHODELOLW\WRUDPSUHVRXUFHVDQGDFFHVVWRDQLQWHUQDWLRQDO market. Focusing solely on cost reduction has turned out to be contra-productive.

But still, it's ever so common that an outsourcing project starts with a clear drive to cut costs, only WRWXUQDURXQGKDOIZD\PRYLQJLQWRÀUHÀJKWLQJPRGH,I QRWZHOOSUHSDUHGDQGPDQDJHGDSURMect can become more expensive than when the outsourced task was done internally. And worse, quality issues may negatively impact customer satisfaction and drive the sales down the drain.

So, we need to get aware of what the real costs are. Too often, the cost and investment calculation are based on a price per person-hour comparison, which hardly give the full picture of the total cost.

We can expect additional costs due to:


This might come without saying, but better safe than sorry: we should expect the running costs for managing the outsourcing partner, requirements and deliveries to be higher compared to if we had continued running the project internally.

Staying in control over the costs, or investments which they rather are, will help us not making hasty decisions when taking on the real challenges.

## We're only human

There will be challenges. Certainly, there are matters we can't predict and matters that are totally out of our control. But many problems that arise in an outsourcing or offshoring project can be traced down to human nature. It's due to how we communicate, how we motivate and are motivated, and make everybody believe in the project (or not), how we make the journey inclusive, and a million other things. We have to deal with them and take these issues seriously.

On our home site, employees will worry about their jobs, even be annoyed over the idea of having to train and transfer their knowledge and work to those that replace them. They will make assumptions, rightly or not, leading to an inner resistance to cooperate. Another challenge is the need to change roles, routines and processes for the staff remaining at the home site. It's not XQXVXDOWKDWFRPSOHWHO\QHZVNLOOVDQGFRPSHWHQFHVDUHUHTXLUHGWRVXSSRUWDQHIÀFLHQWJOREDO delivery set-up.

At an external site in for instance India or China, we should expect it's a challenge to attract and UHFUXLWKLJKO\VNLOOHGHQJLQHHUV0RVWRXWVRXUFLQJSDUWQHUVKDYHJUHDWGLIÀFXOWLHVLQUHWDLQLQJ their staff, resulting in a very high employee turnover. The competition between global engi-QHHULQJFRPSDQLHVWKDWGLSLQWKHVDPHSRRORI VNLOOHGZRUNHUVLVÀHUFH,QGHHGWKHUHDUHPRUH VNLOOHGHQJLQHHUVDYDLODEOHWKDQHYHURQWKHPDUNHWLW·VMXVWYHU\GLIÀFXOWWRKLUHWKHEHVW7KHUH are indeed lots of engineers with knowledge in modern, standard based technologies. But if our V\VWHPLVEXLOWRQROGWHFKQRORJLHVRUUHTXLUHVVSHFLÀFNQRZOHGJHWKH\JHWIHZHU7KLVKDVEHHQ analyzed thoroughly in this and other studies.

## Due diligence

(QRXJKDERXWGLIÀFXOWLHVOHW·VJHWGRZQWREXVLQHVV7RVXFFHHGZLWK a mission such as this, we need to analyze and prioritize the following parameters:

Given the costs, distractions, investment of management time and other hurdles that will come when getting into outsourcing or offshoring, the importance of the due diligence can't be emphasized enough.

## Our strategy

Once having the due diligence done, we're ready to outline our outsourcing or offshoring strategy:

#### Why do we want to outsource, what are our goals? Is the outcome measurable?

It is very critical to set clear goals and expectations because it shapes everything that follows IURPWKLVSRLQW:LWKRXWFOHDUJRDOVZHFDQIRUHVHHXQIXOÀOOHGH[SHFWDWLRQVDQGXQFHUWDLQW\ about the outcome of the entire operation. How would we know if we have succeeded? So, depending on what we want to achieve, what our business drivers are, we could for instance elaborate with the following targets:


#### What do we want to outsource?

We need to make a make-versus-buy analysis to determine what's possible to outsource and what's not. For instance, complex parts that aren't easily decoupled or used by several other projects won't likely be easy to outsource. On the other hand, we might actually want to outsource a part even if it would be cheaper to develop it ourselves. This would for instance be the case if we want to allocate our own resources to more critical activities or if we want to build up and maintain capacity for peaks in our workload. It all depends on our goals. 

Outsourced components are chosen from the use of a Make-Buy strategy

#### Who can we outsource to?

In addition to cost, we need to analyze the third party supplier's competence and maturity, GHYHORSPHQWPHWKRGDQGGHOLYHU\PRGHOWKHLUÀQDQFLDOOHJDODQGVHFXULW\VWDWXV:HQHHGWR understand the political situation, and geographical and cultural contexts. If our development team will be tied up in ongoing projects and our deadline is tight, we could consider bringing in consultancy help. Having clear goals is key to be able to objectively select a partner.

It is critical to stay on top of things and be prepared when the transformation doesn't run as smooth as anticipated. The goals are the cornerstones in the measurements and the quality assurance we need to put in place. Both direct and indirect costs need to be taken into account. 3URDFWLYHGHFLVLRQVQHHGWREHPDGHDWWKHÀUVWVLJQRI GLVFUHSDQFLHVEHWZHHQSODQDQGUHDOLW\ 7RVXFFHHGLQWKLVWUDQVIRUPDWLRQZHQHHGWREHDJLOHDQGÁH[LEOH

#### How can we organize ourselves?

Which new roles will be needed to manage the supplier and their deliverables? While setting up an organization isn't that complicated, transferring necessary product and process knowledge requires substantial effort and time. Not only do we have to make several trips to the supplier's location, staff from both sites will have to meet face to face, not only to get to know one another, but more importantly to better understand the tasks and challenges they face. It is particularly important to introduce incentives for the employees at the outsourcing site in order to minimize staff turnover.

Organizational setup for managing outsourcing

:HOOGHšQHG

processes for

outsourcing

Responsibilities are allocated in organization

## Get inspired

This scenario has been based on case studies of different companies that have made this journey, to scale with Offshoring or Outsourcing. Learn from their experiences, what they gained and what they had to overcome.

#### Efficient communication in a global delivery model

Since this scenario is about the glam of succeeding, and not the gloom of struggling, do pay attention to the case study of Tieto.

#### Outsourcing Strategy at Sony Mobile

Read about the smartphone manufacturer, which journey started like many others at the time, a bit on a bumpy road. Eventually, they scaled into an organization that was able to identify parts that are best suited for outsourcing, to continuously introduce and manage outsourced development projects along with their internal development.

#### Not so shore anymore

This company had an equally bumpy experience when they decided to outsource a system that was not particular well suited for the purpose. It didn't go well, but there are still many lessons to learn from their case.

#### Play it again, Sam, backwards

Another story to learn from is the rise and fall of Sony Ericsson's PlayNow service. It's an excellent example of when bringing development back and run it in-house makes sense. 7KH\VKRXOGQRWKDYHRXWVRXUFHGLQWKHÀUVWSODFH

**Efficient communication** CASE STUDY / Outside the box

## **in a global delivery model**

This case study features Tieto, one of the largest IT suppliers in the Nordic countries. As Tieto operates in many different locations and with different suppliers, which is why they seek ways for HIÀFLHQWFRPPXQLFDWLRQLQDJOREDOGHOLYHU\PRGHO7KHPDLQGULYHUIRURIIVKRULQJZDVWRUHGXFH costs and release personnel for design of the next generation of systems, and at the same time to maintain high system availability and service levels.

7KHV\VWHPZHIRFXVHGRQKDVEHHQLQRSHUDWLRQIRURYHU\HDUVDQGLVFODVVLÀHGDVYHU\ complex with a large number of integrations, databases and functional modules. The system is business critical and used in the daily work by approximately 3,500 users.

7RUHDFKDPRUHFRVWHIÀFLHQWVHWXSDPDMRUSDUWRI WKHGHOLYHU\ZDVWUDQVIHUUHGWRD7LHWR offshore site in Pune, India in 2010. The goal was to reach an offshore ratio of 80% and to keep a team with strategic architectural competence in Sweden.

7KHFDVHVWXG\ZDVSHUIRUPHGÀYH\HDUVDIWHUWKHWUDQVIRUPDWLRQDQGFRQGXFWHGWKURXJKVHYHUDO interviews with persons involved both before and during the transformation. As the level of the offshored activities increased, also the need for project communication and knowledge transfer LQFUHDVHG7KHVHWZRIDFWRUVZHUHODWHULGHQWLÀHGDVEHLQJWKHNH\VXFFHVVIDFWRUVLQWKLVRSHUDtion.

#### The focus of the case study has for that reason been the importance of good communication and knowledge transfer in terms of:


7KHÀUVWVWHSLQWKHWUDQVIRUPDWLRQZDVWRDSSRLQWDQGKLUHUHVRXUFHVLQ,QGLDDQGVHQGWKHPWR Sweden for an 18 weeks training program. Next, senior architects from Sweden were sent to India for 6 months to build up the competence level of staff of the Indian team. To assist training, VSHFLÀFDOO\GHVLJQHGRQOLQHFRXUVHVZHUHRIIHUHGZKLFKZDVDQHIÀFLHQWDSSURDFK7KH,QGLDQ team gradually increased their system knowledge and could take over responsibility for more complex tasks already during the transformation period. The regular visits have continued after the transformation, in both directions.

The goal was to establish "one team" distributed over the two sites. Instead of creating a process where each site was responsible for different phases and deliverables, a single team was built based on the roles that were needed. The purpose was to bridge between the sites and get an HIÀFLHQWFRPPXQLFDWLRQDQGNQRZOHGJHWUDQVIHUZLWKLQWKHWHDP

## Observations

\$GKRFSHHUWRSHHUFRPPXQLFDWLRQSURYHGWREHYHU\HIÀFLHQWLQWKHSUHYLRXV single site organization. Splitting the team over two locations resulted in a more complex communication structure between engineers from different cultures and locations. The team now needed communication solutions such as chat, voice and video conferencing.

The complexity of the system functionality was also problematic. It took longer for the offsite part of the team to learn and understand the solution functionality than the technical solution. The implementation techniques were often quite JHQHULF0RVWGLIÀFXOWWROHDUQZDVKRZHYHUWKHFXVWRPHUVSHFLÀFUHTXLUHPHQWV DQGSURFHVVHVDQGWKHYDULRXVGLIÀFXOWOHJDOFRQVWUDLQWV

Both the Swedish and Indian teams were exposed to new cultures. There are VLJQLÀFDQWGLIIHUHQFHVLQWKHZD\RI ZRUNLQJFRPPXQLFDWLQJDQGFROODERUDWLQJ The Swedes were surprised about the extensive hierarchical approach to responsibilities and roles that were common practice in India. This allowed the Indians WRFUHDWHDQHVFDODWLRQKLHUDUFK\WKDWVLJQLÀFDQWO\VDYHGWLPHDPRQJWKH6ZHGLVK architects.

\$QRWKHUVLJQLÀFDQWFXOWXUDOGLIIHUHQFHZDVKLJKSHUVRQQHOWXUQRYHULQWKH Indian team. To switch employer is common and a cultural norm in India. This turnover requires additional training efforts and jeopardizes successful and sustainable knowledge transfer.

7KHFDVHVWXG\WHDPDOVRQRWHGWKDWFRPPXQLFDWLRQHIÀFLHQF\DSSHDUHGWREH much higher after visits between the two sites. In addition, a business trip to Sweden was regarded as a very attractive goal in itself and highly motivating for the Indian team.

## Recommendation on how to succeed

Make a thorough analysis of the system before selecting competence needs and communication strategies. It is more challenging to get an effective offshore for complex systems, so focus on functional complexity rather than technical solutions.

Decide upon a competence strategy early in the offshoring phase. Take this into account when staff reduction starts at the local site. It's important to secure personnel for future roles available in later phases of offshoring.

Make a visible step-by-step knowledge transfer process. Tailor training programs to areas of expertise and let team members mature over time, area-by-area. Repeat steps per area:


'RQRWXQGHUHVWLPDWHWKHGLIÀFXOW\WRDFKLHYHJRRGDZDUHQHVVLQWKHSURMHFWWRHQVXUHWKDWDOO team members know what is going on.


<sup>201</sup> 199

6RIWZDUHKDVWUDQVIRUPHGWKHPRELOHSKRQHLQGXVWU\:KHUHDVWKHÀUVWPRELOHSKRQHVFRQWDLQHG a minimal amount of software, today mobile phones contain more powerful processors than those used to put man on the moon. This allows modern phones to do much more than just making phone calls, offering many more advanced features. To develop software that makes this possible, all major players in this industry have outsourced some of their software development – and Sony Mobile is no exception. For Sony Mobile, the main driver was to reduce development FRVWVVXVWDLQLQJJURZWKDQGWRPLWLJDWHGLIÀFXOWLHVLQÀQGLQJZHOOWUDLQHGGHYHORSHUV

All these reasons are very common throughout the software industry. Unfortunately, not many companies perform a thorough analysis to evaluate whether cost savings are realistic and achievable. Sony Mobile didn't stick out here either. Too often, companies embark on outsourcing journeys solely to reduce costs based only on a simplistic comparison of the hourly wages of developers. This, however, leads to a completely wrong conclusion when other factors are not included in such calculations. When starting on an outsourcing journey, companies need to spend considerable efforts and expenses on knowledge transfer activities, onboarding, and companies must also anticipate various barriers that might emerge due to more complicated communication that is now hindered by time zones and geographical distance.

Outsourcing partners – the supplier that will do the customer's work – often don't possess the same level of knowledge and experience as the customer company, and often this lack of knowledge is compensated by adding more people to a the project, all of whom take considerable time WREXLOGXSGRPDLQNQRZOHGJH7KLVLVWKHÀUVWZD\LQZKLFKWKHWRWDOFRVWPLJKWHQGXSKLJKHU than anticipated – perhaps more than if the software were developed in-house. Building up domain knowledge takes considerable time. Moreover, this is effectively an investment in the outsourcing supplier, and not the customer's own development staff. For certain outsourced tasks that involves standardized (non-differentiating) technology, this may be an appropriate strategy, and may pay off when a company is building a long-term relationship with a supplier.

Another lesson learned by Sony Mobile is to evaluate carefully what should be outsourced. Sony Mobile has extensive experience with outsourcing, and this has led to the development of a global software outsourcing strategy. They also introduced a shared outsourcing forum for their global development centers, which had been struggling with different outsourcing projects for \HDUV7KHJOREDORXWVRXUFLQJVWUDWHJ\GHÀQHGWZRPDMRUDFWLYLWLHV

Decrease development cost

203 201

7KHÀUVWDFWLYLW\ZDVWRVHFXUHDJOREDODOLJQPHQWRI LQWURGXFLQJRXWVRXUFLQJDFWLYLWLHVDQG outsourcing partners. Projects, partners and all tasks, risks and issues involved in an outsourcing project should be managed systematically and equally. This way, it's possible to achieve synergies DQGLGHQWLI\EHVWSUDFWLFHV³ÀJXULQJRXWZKDWZRUNVDQGZKDWGRHVQ·W6HFXULW\DQGDFFHVVULJKWV management are two key areas where it is very important to use common best practices, because those are critical to Sony Mobile's products.

Furthermore, Sony Mobile created a common reference process framework for analyzing, SUHSDULQJDQGH[HFXWLQJRXWVRXUFLQJSURMHFWVZKLFKGHÀQHVUROHVDQGSURFHVVHVIRUVXSSRUWLQJ outsourcing projects in organization. An outsourcing business manager supports projects in the preparation and execution phases of outsourcing projects. The reference framework also includes a milestone process for approval and execution of each outsourcing projects, which helps to keep track of the stages of the various outsourcing projects within the company.

The second activity was to create a decision framework to help business units analyze and select suitable components to outsource. Using a tool support, business units can evaluate components based on a set of three key parameters.

7KHÀUVWSDUDPHWHUUHIHUVWR**current capabilities**, which refers to competence and amount of resources. What is the current capability for a given component? Is there a lack of competence to implement or maintain the component? Are resources wasted on components that can easily be acquired from a third party supplier?

A second parameter is **dependencies**, including technical and project dependencies. Technical dependencies indicate the extent to which a component is coupled to other modules in the system. Project dependencies indicate the level of usage (or reuse) of a given component by other projects. If a component plays a key role in many systems, this means it is important to an organization as a whole, and such components should not be outsourced.

The third parameter is concerned about **long term control and competence**. This is an indicator of whether or not it is important to be able to control a given component's roadmap and future evolution. When outsourcing (or opensourcing) a component, a certain level of control is lost. Components that represent key assets (or "crown jewels) of a company, Sony Mobile have found it is best to retain development in-house.

If, on the other hand, components are 'commodity assets,' a company will get very little differentiating value from such components. In such cases, it may be a suitable candidate to outsource. Typically, excellent candidates for outsourcing are software assets that are in the maintenance phase or better still, in a dead-end state, where no or limited reuse is to be expected.


CASE STUDY / Outside the box

## **Not so shore anymore**

This is the story of a business unit in a large multinational organization that decided to outsource all development and maintenance of one of their systems. The system was a large product lifecycle management system, which was of critical importance to support the organization in its functioning. The system's architecture was typical for this type of systems, and the system LWVHOI ZDVDFRQÀJXUHGFRPPHUFLDOV\VWHPWKDWZDVWDLORUHGWRWKHRUJDQL]DWLRQ·VQHHGV)XUWKHUmore, the system architecture was extensible by including custom developed modules.

In the years prior to the decision to outsource further development and maintenance, the orga-QL]DWLRQKDGEHQHÀWHGIURPFRQVLGHUDEOHHFRQRPLFJURZWK+RZHYHUPRUHUHFHQWO\WKHRUJDnization suffered from an economic downturn, which led management to establish cost saving strategies. At the same time, the organization had moved away from a traditional waterfall de-YHORSPHQWSURFHVVWRDJLOHDSSURDFKHVEXWVWLOOUHWDLQLQJWKHZDWHUIDOO·VPRGHOIRFXVRQGHÀQLQJ IXQFWLRQDOVSHFLÀFDWLRQV²WKHUHVXOWLQJSURFHVVZDVWKHUHIRUHDK\EULGRQH7KHGHYHORSPHQW organization was still divided in maintenance and development; solution managers were respon-VLEOHIRUWKHFRQWDFWZLWKWKHRUJDQL]DWLRQE\XVLQJWKHV\VWHPDQGGHYHORSIXQFWLRQDOVSHFLÀFDtions with architects and developers.

In order to cut costs, the organization decided to outsource all development activities. In addi-WLRQWRWKHFRVWVDYLQJGULYHUDQRWKHUGULYHUZDVWREHFRPHPRUHÁH[LEOHLQVSHQGLQJUHVRXUFHV on new functionality. The company chose an existing outsourcing supplier that was already used for other large systems within the organization. The organization's requirements on cost savings resulted in a decision of the outsourcing partner to offshore the entire development to another organization in India.

The solution manager and the architecture knowledge were retained in the original organization, while development was moved out. The outsourced part consisted of about ten developers and WHQWHVWHUV,WZDVFOHDUWKDWDSURFHVVEDVHGRQVSHFLÀFDWLRQVZDVQHHGHGZKLFKPHDQWWKDWWKH previous agile transformation was abandoned, and a waterfall model was adopted instead. An implication of this was that the on-site roles became less interesting from a technological point of view, which resulted in the architects leaving the project. This in turn led to a reduction of skilled and experienced staff that was available which was very important for the requirements and design phase.

At the outsourcing organization there were developers as in the original organization, but also team leaders responsible for leading the work and keeping the contact with the original organiza-WLRQ7XUQDURXQGWLPHVIRUGHYHORSPHQWEHFDPHORQJHUDQGLWEHFDPHPXFKPRUHGLIÀFXOWWKDQ DQWLFLSDWHGWRÀQGPRUHVWDII DWWKHRXWVRXUFLQJRUJDQL]DWLRQZKHQPRUHGHYHORSPHQWQHHGHG to be carried out. All the customizations became roadblocks. These forced the developers to undergo a large amount of training before they could be productive. But, despite all the training, WKH\DOVRPLVXQGHUVWRRGWKHVSHFLÀFDWLRQVUHVXOWLQJLQDODUJHQXPEHURI SUREOHPVDWWKHÀUVW major release.

The initial phase was characterized by long lead times, a large number of misunderstandings and ORZÁH[LELOLW\RI UDPSLQJXSGRZQWKHGHYHORSPHQWIRUFHZKHQWKLVZDVQHHGHG7KH\IRFXVHG too much on the formal process instead of having a common view of the development and the system was simply too customized.

After the initial outsourcing phase, efforts were made to improve the understanding of the development from both sides of the organization. Representatives from the outsourcing organization came to visit the original organization. The original organization started also to visit the outsourcing organization more frequently. This resulted in both better understanding of the development and in a more personal commitment to the system and the original organization at the outsourcing organization. However, the architecture was still too customized.

A number of recommendations can been made. Creating a common social group for developers early in the change process would probably have worked better than the starting off with a for-PDOSURFHVVEDVHGRQVSHFLÀFDWLRQVDQGKDQGRYHUV,WZRXOGSUREDEO\DOVRKDYHZRUNHGEHWWHU LI WKHV\VWHPZDVOHVVFXVWRPL]HGZKLFKZRXOGKDYHPDGHLWSRVVLEOHWRÀQGWKHULJKWFRPSHtence already from the beginning at the outsourcing organization. The developers at the outsourcing site could probably have been involved earlier to reduce mistakes and to gain a better understanding about the system and why it was needed.

The organization decided later to take home the development and conduct it at another business unit inside the company. The driver for this was also this time to save costs, but which this time was possible as the business unit that will do the development had about the same cost of developers as the outsourcing organization. With the same cost structure, but with a development RUJDQL]DWLRQFORVHUWRWKHXVHUVZHVLPSO\JHWDPRUHHIÀFLHQWGHYHORSPHQWSURFHVV

211 209

CASE STUDY / Outside the box

## **Play it again, Sam, backwards**

PlayNow was Sony Ericsson's download service for media such as music, games, ringtones, wallpapers and themes. They used to have the bigger part of the PlayNow team outsourced. The development was taken care of by the outsourcing partner and Sony Ericsson took care of the project and product management internally. The outsourcing partner actually desired to have the SURMHFWDQGSURGXFWPDQDJHUVDWWKHLUVLWHWRGULYHWKHVRIWZDUHGHYHORSHUVPRUHHIÀFLHQWO\EXW this never happened. So the set up was very top heavy. Communication could only go between a point-of-contact at each company, causing a lot of time lost. Every three months the outsourcing partner delivered a version of the software delivery. This led to a very slow feedback loop. It ZDVGLIÀFXOWWRNQRZLI ZKDWKDGEHHQGHOLYHUHGDOVRZDVZKDWKDGEHHQGHYHORSHG

Due to cost saving directives, management decided to bring back the software, to develop it in-KRXVH7KLVSURYHGWREHDPRUHHIÀFLHQWZD\WRZRUN7KHFRVWVDYLQJZDVDSSUR[LPDWHO\ even though cost per head-count was increased. This was mainly thanks to reduction of overhead and that they started to work in an agile way with weekly deliveries.

What we can see from the Sony Ericsson case is that it is not always cheaper to outsource. Overhead, communication and innovation were factors that certainly added extra cost to their outsourcing activity. This is not an isolated case, several other companies suffers from the very same problems. A global trend is that the outsourcing market is shrinking. The largest outsourcing deals in the world are far less valuable today than they were ten years ago, according to IDC in the Wall Street Journal.

To decrease costs is one of the most common reasons to outsource, but outsourcing is not always the least costly solution. As in this case, the overhead cost of outsourcing grows that much that it is a lot cheaper to bring home the software development. By having the software development in-house it's easier to keep the project in control and to know what is developed and why. Those aspects are much harder to manage when all development takes place outside of the company walls. Another reason that causes added costs is the growing overhead in the outsourcing organization. Usually only software development costs are included in the cost calculations. But, the outsourcing partner also needs to have project managers, architects, system designers and line managers.

#### "What to do"

LVDERXWšQGLQJWKHUHTXLUH ments from the customers and to communicate them to the software developers.

#### "How, when and where to do it"

is about the software development methodology, how we take on roles and responsibilities and split the organization into a sensible structure. It's about staying in control regarding your source code. Which revision should we work on? Which part of the software have certain part of the functionality?

The first things are about the very basic needs. We need for instance to know what to do and how, when and where to do it. We also need to check the quality of it.

#### "Check the quality of it"

is simply to follow up on the planning and the coding E\GHšQLQJDQGFRQGXFWLQJWHVWV

215

Agood read

**Basic principles and concepts for achieving quality, Emanuel R. Baker, Mattew J. Fisher, 2007**

This might not come as a surprise, but in case our organization has been growing from just about nothing to employ some twenty developers or more, it's likely we have problems with LQVXIÀFLHQWTXDOLW\DQGLQFUHDVLQJPDLQWHQDQFHFRVWV:HKDYHSUREDEO\SUREOHPVZLWKYLVLELOLW\ ZKHQIROORZLQJXSRQSURMHFWVDQGLW·VOLNHO\GLIÀFXOWWRPDNHEXJFRUUHFWLRQVZLWKRXWFDXVLQJ new bugs.

One of the reasons why we have these problems is probably that our organization has outgrown RXUFXUUHQWZD\RI ZRUNLQJ5HGHÀQLQJWKHZD\RI ZRUNLQJWRPDWFKWKHFXUUHQWVL]HRI RXU RUJDQL]DWLRQZLOOLQJHQHUDOOHDGWRLQFUHDVHGTXDOLW\SURGXFWLYLW\DQGHIÀFLHQF\RI WKHEXVLQHVV It will in particular make the projects more predictable.

It's hardly a surprise that growing organizations get problems. To do a good job, basically developers need to know "what to do" and "how, when and where to do it". As easy as one, two WKUHHRQHPLJKWWKLQN\$VDPDWWHURI IDFWLWJHWVPRUHDQGPRUHGLIÀFXOWWRVSUHDGLQIRUPDWLRQ as the organization grows. What isn't a problem to communicate between very few developers, simply is more complicated in a larger team. It isn't rocket science. We recognize this from all sorts of contexts, not just business. Yet most software projects fail in their communication. Only a software organization in possession of these basic capabilities can be scaled to meet the demands of today; if not with ease, at least without the chaos it would cause to not have them.

To state the obvious, our engineers need to know what to do and how to test what they have done. The requirements need to be communicated in a way that they understand. While there are many ways to manage requirements and every way comes with its pros and cons, most important is that we do it.

Growing the software labor effort from one or two developers to more than 15 to 30 developers puts great demands on both the software process and the software architecture. While two GHYHORSHUVFRXOGKDQGOHUHTXLUHPHQWVFRQÀJXUDWLRQPDQDJHPHQWTXDOLW\DVVXUDQFHSURMHFW planning and follow up in an informal way, the larger team simply runs into serious communication problems.

All engineers need to know their roles and responsibilities. The organizational structure must facilitate effective communication in all directions, not just vertically. The optimal structure closely follows the ways people work, weather they work in projects or in a product line. Agile development methodology, which nowadays is the de-facto way of working, promotes for instance self-organized teams that in its most extreme implementation can be seen as companies in the company. It's safe to say that we should avoid old school hierarchies that merely organize people on what they do.

About those ever-late projects of ours, they need to be dealt with. It's not that our current project managers aren't doing their job; it's just that they have to change direction every now and then. The ways to plan have to be adapted to the reality, where plans are revised continuously. It's wise, though, to not overdo the planning and instead try to capture the few next weeks in detail. In Agile development methodologies, already mentioned, all planning is made in twoweek chunks. Trying to grasp a much longer period of time into a plan has simply shown to be doomed to fail.

In what state is our software architecture and how do we manage it? The software has to serve LWVSXUSRVHWRIXOÀOOWKHIXQFWLRQIRUZKLFKLWZDVFUHDWHG,WPXVWDOVREHÀUPLQWHUPVRI structural integrity and durability. If optimally designed we should be able to:


,W·VNH\WRGHVLJQWKHV\VWHPDVDVHWRI FOHDUFXWSDUWVHPERG\LQJZHOOGHÀQHGERXQGDULHV6RIWware architecture is, simply put, how these parts are structured and how they relate and communicate with one another. The architecture starts with its documentation, a blueprint that governs how to design parts in order to facilitate development of the software system. And, as with ways of working has the organization to tightly follow the architecture.

Finally, we have the testing. Is this activity considered the necessary evil that continuously gets down prioritized when the project slips in time? If so, we should really be cleverer. To monitor and evaluate how the organization is doing quality-wise pays of as soon as the heat is turned on and the business gets into full production mode. When everyone involved runs as fast as they can, occasionally even making short cuts to get in time, there's simply no room for thinking about what can be improved. The test activity is really our only mean to identify bottlenecks and to optimize processes and tools.

Optimally, to ensure we're going in the right direction, both the plan and the software ought to be followed up on. This shouldn't be done at the end of the project but frequently, tightly coupled with the iterations in which development takes place. We would want to keep the feedback loop as short as possible. All Agile development methods have this built-in to the method. At the end of the iteration, an automatic test script would test the software and a retrospect would evaluate if we work in a good way or if a change of direction is needed.


## Get inspired

Being one of the engineering disciplines mostly written about, you shouldn't have to go far WRÀQGLQGHSWKVXFFHVVVWRULHVDQGOHVVRQVOHDUQHGIURPGLYHUVHHIIRUWVLQVWUDLWHQLQJXS software organizations and architectures. The following pages summarize the real-life case VWXGLHVWKDWZHUHFRQGXFWHGWRGHÀQHWKLVVFHQDULR

#### Robotic growing pains

Read about Husqvarna's experience when they added Internet of Things to some of their lawn and garden products.

#### Softhouse reflects on architecture changes

Learn about the effects of architectural changes in Android development.

#### From mobile to platform

7KHSODWIRUPFRQFHSWEXLOGVRQFRPSRQHQWVWKDWHDVLO\FDQEHFKDQJHGRUFRQÀJXUHG7KLV enables new products and offerings to be created quickly, without having to redo a lot.

## One more thing

When scaling through *)LUVW WKLQJV ÀUVW* a development method has to be chosen. As we have hinted throughout this scenario, it is strongly recommended to work in an agile way. Find canvases for Agile development in the chapters **Pump up the volume**, **Deliver 24/7** and **Agile and disciplined**.

Husqvarna Robotics had grown from a small team of 3 software engineers to over 30 software engineers in a very short time. They understood they needed to improve their quality and project predictability because of the problems they had with their software development.

Robotics had started to get problems with late deliveries, bug corrections very often led to new more serious problems, and new bugs reports from the market disturbed the software team in their work to develop new functionality, this led to delayed software projects and releases. Project PDQDJHUVZHUHQRWFRQÀGHQWWKDWWKHVRIWZDUHWHDPFRXOGGHOLYHUDFFRUGLQJWRWKHSODQ\$UFKLtecture improvements were pushed in the future, due to lack of time. The testers did not have time to test everything in a release, which led to even more bugs being reported from the market.

Project management did not know which requirements being implemented at the moment. There was little visibility of the progress in the software team. All software was delivered late to the main branch. At that time a major part of functionality did not work, so what was working or not wouldn't be discovered until very close to the release of the product.

3URGXFWPDQDJHPHQWGLGQRWKDYHFRQÀGHQFHLQWKDWWKHVRIWZDUHRUJDQL]DWLRQZDVGHOLYHULQJ QHZIXQFWLRQDOLW\HIÀFLHQWO\

During fall 2014 a series of general seminars in software engineering was conducted in the entire R&D organization. Robotics understood it would be good to get external help to do an analysis of the current situation. A kick-off of the improvement project at Robotics was held in September 2014. A series of interviews was held and a report of the situation and improvement proposals was presented in January 2015.

Suggestions of improvements were made for the areas such as requirement handling, project SODQQLQJSURMHFWWUDFNLQJVRIWZDUHTXDOLW\DVVXUDQFHDQGFRQÀJXUDWLRQPDQDJHPHQW,WZDVDOVR said that the software architecture needed to be restructured.

A new meeting was held to agree on which changes to prioritize. The software organization, project management and product management were all involved in this decision.

The most important suggestions of improvements from the audit were prioritized to be imple-PHQWHGGXULQJWKHÀUVWKDOI RI

In April 2016 the software organization had a completely new situation. Instead of the negative atmosphere that characterized 2014, a more positive attitude characterized the organization. The software team was positive to the new ways of working and they believed they were working in a good way.

%\WKHHQGRI WKHLQLWLDOWHDPRI WKUHHKDGOHIWWKHFRPSDQ\7KH\GLGQRWÀQGWKHLUSODFH in the larger organization. Even though this was a large competence loss, the organization was now better prepared for situations like this. The new ways of working and the new documented architecture made the organization less dependent on a few very competent champions.

Husqvarna has in this project gone through a very common growth problem. The exact same problems were found in several different Ericsson departments in the early nineties and have been found in several other companies since then.

CASE STUDY / First things first

## **Softhouse reflects on architecture changes**

228 226

A typical situation in software development is that a product is developed as a prototype or as a ÀUVWYHUVLRQEXWLQDUDWKHUVPDOOVFDOHDQGWKHQWKHSURGXFWDQGWKHQXPEHURI LQFOXGHGIXQFtions grow. One problem with this is that the software architecture might not be suited for what it is used for, thus resulting in added functionality that causes unpredictable software faults. It gets necessary to improve the architecture through refactoring. This happened to Softhouse.

There were three main reasons for Softhouse to make a change in the software architecture:


Starting as a small prototype, they created a client system to provide their customers with data from their internal information systems. As the usage of the client system grew, the product itself and the number of functions increased rapidly. A problem was for instance that any changes in the product affected many parts of it, which resulted in unpredicted faults.

The system was built with focus on reuse, i.e. when new functionality was added, existing classes were reused as much as possible. This focus lead to an architecture with many dependencies UHVXOWLQJLQDPRQROLWKLFV\VWHP7KLVZDVLGHQWLÀHGDVWKHUHDVRQEHKLQGWKHPDQ\TXDOLW\LVVXHV To make the design less fragile, the architecture was divided into modules. Each module imple-PHQWHGRQHVSHFLÀFIXQFWLRQSURYLGHGWRWKHXVHU)XQFWLRQDOGHFRXSOLQJDOORZHGWKHGHYHORSHUV WRPDNHFRUUHFWLRQVRUXSGDWHVRI H[LVWLQJIXQFWLRQVPRUHHIÀFLHQWO\DQGZLWKKLJKHUTXDOLW\,W also allowed for parallel updates of different functions at the same time. It also allowed for introduction of new functionality independent of the existing ones.

The architecture guidelines were changed to stress on the use of independent modules and how to manage them individually. Drawbacks of architectures like this are less reuse and more double maintenance of similar code in different modules. However, changes can mostly be limited to RQHPRGXOHDQGWKHUHIRUHIXOÀOOWKHPDLQWDLQDELOLW\UHTXLUHPHQWV

The project followed an agile approach similar to Scrum with collective code ownership where the developers assign the tasks to themselves. The new process allows developers to avoid change requests in modules they haven't knowledge in. From an organizational perspective, the new architecture makes it easier to scale. New developers that join the project can start work on one function in one module and learn the system function-by-function. The new software architecture is now used in full effect.

To move towards a platform development strategy, where the same software is used in many SURGXFWVLVTXLWHQDWXUDODQGDFRPPRQVWUDWHJ\LQPDQ\FRPSDQLHV\$IWHUWKHÀUVWSURGXFWKDV been successfully released, the company now looks for ways to grow the business and to reuse the investments already being made.

The platform concept builds on modularized, stable and reusable components that easily can be FKDQJHGRUFRQÀJXUHG7KLVHQDEOHVQHZSURGXFWVDQGRIIHULQJVWREHFUHDWHGTXLFNO\ZLWKRXW having to redo a lot. However, the strategy and its implementation is always an act of balance between reuse and product focus.

:KHQ6RQ\(ULFVVRQVWDUWHGWRWDNHRII DIWHUWKHVXFFHVVZLWKWKHLUÀUVWPRELOHSKRQHVDOO their activities took place in product projects. There were two similar product development organizations with redundant development competence as a way to develop more than one SURGXFWDWDWLPH\$IWHUWKHÀUVWSURGXFWVKDGEHHQUHOHDVHGWKHUHZDVDQHHGWRLQFUHDVHWKH business and offering even more. It was of course not possible to scale up the development capacity linear to the number of products in the portfolio. So a platform concept was introduced.

The old software architecture was heavily impacted by the platform concept. Modularizing and OD\HULQJRI WKHDUFKLWHFWXUHWRJHWKHUZLWKDFRQÀJXUDWLRQDQGFXVWRPL]DWLRQIUDPHZRUNZHUH key concepts and patterns in order to create the platform concept. It was essential to identify FRPPRQIXQFWLRQDOLW\DQGWKLQJVWKDWQHHGHGWREHFXVWRPL]HGLQFUHDWLQJWKHFRQÀJXUDWLRQ and customization framework.

This made it possible to maintain and reuse the majority of the software and functionality and WKXVRQO\ZRUNZLWKFRQÀJXUDWLRQVDQGVRPHSURGXFWDQGFXVWRPHUVSHFLÀFGHYHORSPHQW7KLV also led to that the number of product variants grew dramatically.

This in turn had an impact on both the processes and the organization. The soft-ZDUH FRQÀJXUDWLRQ GHSDUWPHQW JUHZ DQG EHFDPH WKH KHDUW DQG HQJLQH RI WKH GHYHORSment. A special software release management organization and process were established WR FRSHZLWKWKHODUJH QXPEHU RI YDULDQWV+RZWRWHVW DQGYHULI\LQ D FRVW HIÀFLHQWZD\ EH-

Modularization & Layere<sup>d</sup> architecture

Line

organization =

Project

organization

Product & Platform FRQšJXUDWLRQcomponents

233 231

came the billion-dollar question, as they couldn't multiply the test activities in a linear way. 7KH\KDGWRÀQGZD\VWRDOVRUHXVHWHVWDQGYHULÀFDWLRQLQDVPDUWZD\

Sony Ericsson was successful in this journey since they were able to release more and more products without having to increase the work force in a corresponding way. The time-to-market DQGFRVWSHUSURGXFWUHGXFHGVLJQLÀFDQWO\

– So did they continue to improve and become better and better?

234 232

#### The answer is no.

As the platform concept grew stronger and stronger the focus on the product itself and its offering became weaker. The platform projects and its organization grew bigger and bigger and tried to include more and more products in its releases. Together with a waterfall approach WKLVOHGWRWKDWWKHSODWIRUPSURMHFWVEHFDPHVORZDQGLQÁH[LEOHJLDQWV7KHVHWULHGWRSOHDVHDOO products with all their market and customer needs. This also made the projects lengthy as not all products were released at the same time. As a way to cope with all the products and requirements, the platform projects started to claim that all requirements had to be set at least two and a half to three years prior to the product releases. This was not possible in the mobile industry during mid-2000, as tons of new features and concepts were released every year.

The organization and process became impossible to maneuver and the product offerings became late and were not competitive enough on the very tough mobile phone market.

The lesson learned is that a platform concept that is well prepared and balanced with a continuous product and customer focus can lower time to market and reduce development cost. But LW·VDQDUWRI EDODQFHWRÀQGWKHRSWLPXPOHYHORI DEVWUDFWLRQWRZKDWH[WHQWLWLVUHDVRQDEOHWR reuse system components.

235 233

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

B. Fitzgerald et al., *Scaling a Software Business*, DOI 10.1007/978-3-319-53116-8\_3 © The Author(s) 2017

Please come in. Welcome to our home turf. It's time to roll up your VOHHYHVDQGšOOWKHZKLWHERDUG<RXőOOšQGWKH Post-It notes on the table. We've already put up blue ones. As usual these represent your input, what we'd like to achieve. Now, go ahead and šOOWKHERDUGZLWKRUDQJHDQG\HOORZRQHV'HVFULEH what changes you think it would take. Wearing your glasses, consider the impact on our organization, on our ways of working and on our offering. Needless to say, before you jot down your note, browse through the shelf with notes from previous experiences.

'HÀQLQJDWUDQVIRUPDWLRQMRXUQH\LVDQLPSRUWDQWVWHSLQWKHWUDQVIRUPDWLRQSURFHVV,QWKLV chapter we'll show how to setup a workshop to identify the steps that an organization can take to embark on a software scaling transformation. The proposed solution from the workshop will be a concrete list of transitions describing changes in the three key domains that the Scaling 0DQDJHPHQW)UDPHZRUN60)GHÀQHVSURGXFWSURFHVVDQGRUJDQL]DWLRQ:H·OOXVHDFDQYDV throughout the workshop to support this process.

#### The workshop in short:


## Setting up the workshop

'HÀQLQJDWUDQVIRUPDWLRQSURFHVVLVQ·WMXVWVLPSO\IROORZLQJDVHWRI VWHSV²LWUHTXLUHVWKRXJKWIXO participation and creativity. However, using the canvas to structure the ideas and drive the process ZLOOPDNHWKLVPRUHHIÀFLHQWDQGPRUHIXQ,WDOVRKHOSVLQFRPPXQLFDWLQJWKHUHVXOWVWRDZLGHU audience, varying from other managers to developers.

Running a successful workshop depends heavily on active participation and brainstorming by all participants. It's important to get everybody engaged to encourage innovative and creative contributions. This can be achieved by actively coaching this process and asking open questions, but beware of critical comments and feedback that might discourage participants. Later on in the process, the pros and cons of different strategies are evaluated before decisions are made. We won't go into different theories and techniques on how to optimize the workshop phases and group dynamics. Instead, we'll focus on the purpose and content of each phase, and how we use the SMF and the canvas to support the process.

To get started, you'll need to have access to all decision makers in the organization. Remember to cover input from both management who understand the drivers, and from specialists from all three SMF domains: product, process, and organization. As illustrated in the introduction, it's possible to divide the work into two workshops without having all persons on site at the same time. However, when possible it is always best to gather all roles and skills in the same room at the same time, and let them work iteratively together.

#### **Some practicalities before we start the Àrst workshop:**

Make sure that the room is equipped with a whiteboard and a projector that can display the canvas on the whiteboard. Being able to put up post-it notes and connecting them with lines and arrows is important.

\*HWSRVWLWQRWHVLQGLIIHUHQWFRORUVSUHIHUDEO\LQÀYHFRORUVEOXHRUDQJH\HOORZJUHHQDQGUHG :HXVHFRORUVPRVWO\EHFDXVHZHÀQGLWHDVLHUWRSXWWKHPLQWRFRQWH[WZKHQGLVFXVVLQJWKHP together, to get a good overview of the situation. Actually, for most post-its, its place in the canvas tells what type it is. The color is mostly redundant, but the visual distinction can help. There is one place where it isn't redundant, so you will need at least two colors to distinguish the meaning.

## Let's start! Why are we here?

Put the SMF canvas on the whiteboard. Present the goal and the expectations of the workshop and explain how the workshop will be performed.

The goal is to create a list of transitions to be implemented in order to reach a couple of goals DQGDELOLWLHV7KHVHDUHW\SLFDOO\LGHQWLÀHGDVGULYHUVEDVHGRQWKHFRPSDQ\VWUDWHJ\

In order to reach this goal there are a couple of sub-targets. Although this is an iterative process, it's good to know the purpose and goal of each phase (sub target).

## What is our strategy? - What are the drivers?

7KHÀUVWVWHSWRVHWWKHFRXUVHLVWRGHÀQHWKHGULYHUVIRUWKHQHHGWRVFDOH'ULYHUVDUHWKH reasons why we need and want to scale our software, and are often closely aligned to the company's strategy. Typical drivers are a desire to enter a new market or market segment, or to become more innovative. Rapidly expanding organizations can also suffer from growing pains, for example when if the software architecture doesn't scale with the organization, or when well-trained VWDII LVKDUGWRÀQG

#### Start with the external drivers

Most drivers are external, i.e. derived from outside the company. It can be customers, markets, or global regulatory requirements that want us to make the changes. To get our brain to start formulating these drivers we can ask questions like:


Utilize the help from the structure of the "driver groups" and ask what really drives the compa-

ny to a successful future. Is it the OPEX cost that needs to be lowered or is it rather a complete new business model that will outperform our competitors?

Fill the top area of the canvas with blue post-its, each with a driver. This can be done in many ways. For example, we can let the participants do this one by one. We can also do it in small groups and ask one person from each group to present and argue why the drivers are important to have from an external point of view. It's important that all post-its are discussed and understood (and maybe even rephrased) by everybody before being put on the canvas.

When all notes are on the canvas we most likely need to group and reduce them according to a prioritization.


Put the drivers on the canvas in priority order from left to right.

#### Good things we want to keep

The drivers primarily capture things we want to change in order to scale. However, at this point LWFDQDOVRKDSSHQWKDWWKHUHDUHSURSRVDOVWKDWDWÀUVWJODQFHVHHPJRRGEXWDWWKHODWHUGLVFXVsion turn out to have negative impact on already existing (good) drivers. Here we have the possibility to remember this by creating post-it for a driver we want to keep. Keep these post-it notes to the right on the driver's area, to distinguish these as external drivers.

#### Continue with internal drivers

Most drivers are external, but sometimes we also have internal drivers. These are things the FXVWRPHURUPDUNHWQRWVSHFLÀFDOO\DVNIRUEXWZHVWLOOZDQWWRDFKLHYHDVZHWKLQNLWLVWKHULJKW direction for the future. Ask questions like:


Generate blue post-it notes. Explain, discuss and prioritize them. Add the most important to the left of the external drivers. Post-it notes that are removed due to prioritization can be stored in a "parking lot" for later retrieval if needed.

# **3**

## Desired abilities and current inabilities

Now when we have all the blue post-it notes in place, next up is to identify the abilities. Abilities are aspects of the software development such as cost, performance, and quality, which are possible to measure without knowing any details of how the development is made. In the workshop the goal is not to create all-covering measurements of the entire software development, but we will focus on abilities we need to have in order to meet the drivers, the desired abilities. We will also identify the current inabilities, the abilities we have today that we need to improve in order to get the desired abilities. Start by looking at the drivers and formulate measures related

to them. If the drivers are about customer satisfaction, and product quality, the desired abilities

will most likely be about number of issues, customer satisfaction survey results or time to market. ,QDFRPSDQ\ZRUNVZLWK.3,VKRSHIXOO\ZHZLOOÀQGRXU'ULYHVLQWKHVH

**The desired abilities will be the µDeÀnition of doneµ in the implementation phase, so look carefully at them and ask, "Have we succeeded if we reach this?".**

When the desired abilities are in place continue with the current inabilities. What is it that is not good enough – what are our growing pains? Obviously, many of them will be similar to the desired abilities, like for instance customer support availability: a desired ability is 24/7, but current LQDELOLW\LVRIÀFHKRXUV

Put up post-its both for the desired abilities and the inabilities and make sure they cover all the drivers.

### Iterative process

**n**

To identify drivers, desired abilities, and inabilities is an important sub target. It often UHTXLUHVDQLWHUDWLYHZRUNÁRZFRQVLGHU-

ing the software development as a black ER[WKDW GRHVQ·W ÀQLVKXQWLOZH DUH RQ FRPmon ground with the company's strategy and vision.

,QPDQ\FRPSDQLHVWKHSHRSOHWKDWGHÀQH drivers and abilities, and the people that can break these down in terms of organization, process and product, are not the same. In VXFKFDVHVLW·VSRVVLEOHWRÀUVWKDYHDOLPited workshop with management only, to decide on drivers and identify abilities, and use this outcome as input for a subsequent workshop .

## Explain current abilities with domain capabilities

Now it's time to open the black box. We need to understand why we have inabilities, we need to analyze and describe our current situation as is.

Ask challenging questions within all three domains: product, organization, and process. Identify the current domain characteristics that potentially are the problems causing the inabilities. Find

characteristics, that if changed will solve or remove the current inabilities. A domain characteristic is simply explained as a hallmark for the company's software development. Examples of such are "manual test and delivery," "no routines for source code management" and "no process for customer requirements."

Don't just look for the no-brainers, we might have to QHVWDQGDVN´ZK\µIRUTXLWHDZKLOHWRÀQGWKHURRW cause. Why do we have a manual test? Maybe is it because we lack the competence to create automatic tests. If so, this is a yellow note in the organization domain rather than one in the process domain – or both with a line in between depicting the relationship.

During this phase we really need domain experts, people from the company that know how things actually work. What are the actual practices that are used? What does the product architecture look like and what affects on the abilities does it have?

Troubleshooting requires deep knowledge about dependencies - causes and effects. This means we also need people with good general knowledge about the domains and the characteristics of different solutions. If the knowledge can't be found within the company, bring in external competence to the workshop. Such people can also assist as moderators and help getting a holistic view of the discussion.

Use the building blocks within the domains to, in a structured way think through how we actually work and why. In the organization domain, go through all four blocks (structure, culture and leadership, people management, and improvements) to search for reasons to the inabilities. Let the experts from this domain shortly explain the current characteristics of each building block. Discuss if we should add a yellow note.

8VHFRPSHWHQFHIURPDOOWKUHHGRPDLQVWRUHDOO\ÀQGWKHUHDVRQVWRWKHLQDELOLWLHVZKDWSUHYHQWV us from reaching the desired abilities. Put up yellow notes and draw arrows between them to show dependencies.

Don't stop until all inabilities are explained by at least one domain characteristic. For non-obvious relations, draw an arrow in the canvas, from the yellow domain characteristic to the orange inability.

## Find a solution

Now the creative part starts. We need to decide on what changes to make in order to improve DQGPHHWWKHDELOLWLHVDQGGULYHUV,QRWKHUZRUGVZHQHHGWRGHÀQHWKHWUDQVLWLRQVWKHFRPSDQ\ needs to do.

The goal is to have yellow post-its in the WKUHH VRIWZDUH GRPDLQV IXOÀOOLQJWKH GHsired abilities. Each yellow note in the as-is domain should have a transition explaining how it is transformed into the desired solution. When not obvious, draw arrows depicting the transitions. Similarly, all yellow notes in the desired domain should have corresponding transitions needed to have them implemented.

In reality, this isn't so easy. Most likely there will be many alternative transitions with different pros and cons and no obvious "silver bullet" solution. Also, a transition in one domain may also affect other domains. As an example, to make a quite obvious change to a process might also call for changes to the organization, e.g. new skills needed. In these cases, we

need to add yellow notes also explaining the needed "supportive" desired domain characteristics.

Make sure to evaluate different transition possibilities. Also make sure that all desired abilities KDYHEHHQDGGUHVVHGEHIRUHWKHÀQDOVHWRI WUDQVLWLRQVLVGHÀQHG

## Use the body of knowledge and experiences to be creative

\$OWKRXJK ERWK ÀQGLQJWKH URRW FDXVHV DQG VHDUFKLQJ IRUWKH EHVW VROXWLRQ DUH DYHU\ creative tasks, it is also here we can use this book to utilize the experience from previous situations in other companies. Journeys and travel stories provides us examples and captured experience from other companies who have been through similar situations.

**6**

7KHEHVWZD\WRÀQGUHOHYDQWVFHQDULRVLVWRORRNDW\RXUGULYHUV,QZKLFKRQHRI WKHÀYH main driver groups do you see your drivers. Then, go to the "The compass" part of the ERRNWRÀQGUHOHYDQWVFHQDULRVWRUHDGIRU\RXUGULYHUJURXS

An alternative way of using the book is if you want to know how companies similar to yours KDYHGRQH%URZVHWKURXJKWKHMRXUQH\VDQGVHHLI \RXFDQÀQGDFRPSDQ\UHOHYDQWIRU\RX \$VHYHU\MRXUQH\LVH[HPSOLÀHGZLWKVHYHUDO7UDYHOVWRULHVZHHQFRXUDJH\RXWRUHDGWKH entire journey for the selected stories. The canvas for each journey and Travel story gives a quick overview in order to determine if a more thorough read is needed.

### Decision time

All sorts of design ideas have been discussed, pros and cons argued, and trade-offs worked out. It's time to outline the initial change project.

:KHQWKHFKDUDFWHULVWLFVRI WKHIXWXUHVRIWZDUHPRGHOKDYHEHHQGHÀQHGDQGZHNQRZZKDW changes we need to make, document the changes. Start with the main transitions and draw arrows to show how the new domain characteristics result in the desired abilities.

As we know we might need additional transitions to create the pre-conditions needed for the main transitions, add also these to the canvas and draw arrows to show how they support the main characteristics.

\$WODVWLI ZHQHHGWRH[HFXWHWKHWUDQVLWLRQVLQDQ\VSHFLÀFRUGHUDOVRDGGQRWHVRUDUURZVWKDW describe the dependencies between the transitions.

Use the dependencies between the transitions and put together an ordered list of transformations. This list can be used throughout the implementation of the change. In the next chapter you will see how to succeed with the actual change implementation phase.

... most organizations lack all the skills needed to implement and optimize business processes ... Successful process management requires an agile iterative approach to process change.

Gartner Inc.

The Scaling Management Framework will help you to identify the transformation journey to take. It can also help you in dividing the transformation project into reasonable steps. While understanding what to do is crucial, it's not the same thing as knowing how to do it. Every change needs success criteria, a project team, a plan and a budget. However, the planning accuracy is not saying if your change project will be a success or not.

A successful implementation requires a lot of work from all employees involved. Everyone needs to understand why there is a need for change. They have to acknowledge the reason that drives the change and understand how it affects the organization and the ways of working. If it isn't clear "what's in it for me," there is a risk that the project will meet resistance from the employees.

One obvious factor for success is the ownership and the attention from management. High-level progress should be communicated from top management and not only from the project leaders, which should focus on more detailed information sharing. Visibility and transparency in the change process is a key aspect to grow trust and motivation among the employees. The management team should also support the project removing any impediments that might arise during implementation.

A change project can be set up similar to an agile project. Using a prioritized change backlog, use small iterations and retrospectives to minimize the work in progress and keep the lead-time short. The agile change process provides a lot of tools to follow up the results and track the progress. All measurements should help to drive the change (or at least not slow them down) and serves also to reinforce the motivation.

## Agile change center

The Agile change center is a framework for guiding any transformation, based on the same principles that guide agile development. Through determined commitment to small, continuous and incremental change, the Agile change center may be used to investigate, propose, facilitate, execute and deliver any of the change scenarios presented in this book.

The Agile change center primarily seeks to accelerate the transformation and provide:


The center consists basically of two teams, the management and the doers. The management WHDPGHÀQHVGULYHUVDQGSULRULWL]HVDQGDOLJQVWKHRYHUDOOWUDQVIRUPDWLRQ7KH\VHWDOOGULYHUV VXFKDVJRDOVEDVHGRQVDOHVJURZWKRUUHWXUQRI LQYHVWPHQW7KH\KDYHDOVRLGHQWLÀHGDELOLWLHV that they want to measure on, critical success factors of the transformation.

The implementation teams are manned with all necessary competences to roll out the transformation. Two important members of such a team is the transformation owner, who represents the management team, and the Agile coach, who facilitates the performance, learning and development of the individuals in the team, as well as the team per se.

7KHPDQDJHPHQWWHDPPHHWVHYHU\²ZHHNVWRUHÀQHWKHFKDQJHEDFNORJSULRULWL]HFKDQJH items and to follow up on previous change items. The change backlog contains all actions in the transformation. It's basically a list of change Items that is prioritized by the management team. A change item can be any opportunity for improvement, in any of the three SMF domains. The opportunities can be expressed as impediments of a problem, investigations, proposals or suggestions.

The implementation teams meet every 1–2 weeks, for iteration planning and commitments, to review progress and give feedback and to look back at changes that already have taken place. All but the transformation owner meet as well every one or two days to synchronize work, raise GLIÀFXOWLHVDQGDVNIRUKHOS

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

B. Fitzgerald et al., *Scaling a Software Business*, DOI 10.1007/978-3-319-53116-8 © The Author(s) 2017

 **Defini t**

## Alphabetical list of terms and definitions






**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.